SCSM Troubleshooting: MonitoringHost.exe no longer runs and Connectors not working

  • Article

Introduction

This issue seems to be around a lot especially with workarounds and solutions which may vary depending on which one works.

There are multiple fixes for this alongside a solution which I have implemented which seems to get it working 100% and also future references which will allow you to avoid this issue before it’s too late.

Symptoms

Mainly the “MonitoringHost.exe” process which it may show as this or shown as “System Center Management Service Host Process” will not show within the Task Manager processes.

And if you try to manually execute it in “%ProgramFiles%\Microsoft System Center\Service Manager\MonitoringHost.exe”, it will run for approximately 15 seconds and then just drop.

Workflows will be affected by this and will cease to work if creating any work items to be processed. And in my case, all of the Connectors stopped working and every time you click to synchronize it will not update.

You will see events in the OperationsManager event log showing the connector starting and ending within the same second, and the OperationsManager CI Connector will also just start whether it has an out of date or received new data configuration.

Workarounds

Work Around 1 - Clear HealthState Service Cache

  • Stop the System Center Management Service
  • Go into %ProgramFiles%\Microsoft System Center\Service Manager\Health Service State and delete everything inside.
  • Then start the System Center Management Service and look into the Task Manager again and see if they are now showing

Also try to run the MontoringHost.exe from an elevated command line.

Work Around 2 - Validate the Workflow Account credentials

Make sure that your workflow account has local administrator rights on the Management Server.

Solution Prerequisites – Remove Orphaned Connectors (if not working or running and ending)

For the connectors that don’t work or cannot be configured again you will need to remove these as they are now considered to be orphaned connectors.

The SMLets which can be downloaded here https://github.com/SMLets/SMLets/releases

This will allow you to remove the connectors by using the following commands;

To get a list of your connectors use the following command after importing the SMLets module

Get-SCSMObject –Class (Get-SCSMClass –Name Microsoft.SystemCenter.Connector)

Then to remove them enter the following command

Get-SCSMObject –Class (Get-SCSMClass –Name Microsoft.SystemCenter.Connector) | ?{$_.DisplayName –eq “<Connector Name>”} | Remove-SCSMObject –Force –Confirm

Solutions

Solution 1 - Check the SCOM Agent Settings within Service Manager Management Server

When I looked into the Control Panel – System and Security – Microsoft Monitoring Agent I noticed that this was blank as I had set this up initially for the SCOM server to monitor its services.

So, I went into the settings and added a connection to my SCOM Management Server which will automatically restart the System Center Management Service and Microsoft Monitoring Agent Service.

After that all of the “System Center Management Service Host Process” processes appeared and all of my workflows start to work again.

Solution 2 - Check if the Registry Keys for the SCSM Management Group exist

In rare cases it could be that registry keys are missing after System Center Operations Manager (SCOM) Maintenance with the local Microsoft Monitoring Agent Service on SCSM Management Service. The keys with the Name of the SCSM Management Group should exist in [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Server Management Groups] and [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HealthService\Parameters\Management Groups] . If they do exists re-create them.

The key for  [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HealthService\Parameters\Management Groups]  we found in HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\HealthService\Parameters\Management Groups].

The [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Server Management Groups] we got from another SCSM Management Server and changed the name of the SCSM Management Group.

Solution 3 – Re-import the Service Manager Linking Framework Configuration

Check if this management pack is missing, as this is normally the main cause for the connectors not to work at all. If missing (and also if not) you can try to re-import this unsealed management pack as this contains the configuration of any connector you create within SCSM.

It should be located in your installation folder on “C:\Program Files\Microsoft System Center\Service Manager\ServiceManager.LinkingFramework.Configuration”

Future Reference

These best practices are the best ways to ensure that you do not see this issue or ensure that you no longer face this issue again

  • These issues can normally happen if you attempt to remove or do too many updates to the “Service Manager Configuration Management Library” which is default MP it goes to when creating any custom objects. As best practice when creating any custom views or any custom objects ensure that you create a New Management pack which contains these settings, it makes the dependency a lot easier to manage in case of any issues in which you need to remove any management packs and face a complication in which foundational management packs would have to be removed in order to re-import back
  • Rebuilding SCSM using the same database will not work at all. However, you can build a secondary Management Server and switch over the primary function to the secondary which is also a good workaround, but to have a dud Service Management Server within the hierarchy can cause later issues
  • Create a backup schedule for your Service Manager and Data Warehouse databases alongside side the encryption keys so that you have a baseline marker if this issue was to occur again.