Menu Close

How to get your agents back to “Remotely Manageable” in SCOM

You may notice that there are actions you might want to take on an agent, that are grayed out and not available in the console.

There actions might include:

  • Change Primary Management Server
  • Repair
  • Uninstall

See the below image for an example:



This is caused by a flag in the database, which has marked that particular agent as “Not Remotely Manageable”… or “IsManuallyInstalled”.


In order to better see this setting in the UI – you need to personalize the “Agent Managed” view.  Right click in the header bar at the top of the “Agent Managed” view, near where it says “Health State” and choose “Personalize View”



In the view options – add the “Remotely Manageable” column:



Now – you can sort by this column and easily find the agents that you have no control over in the console:



***Another thing to note – is if the “Remotely Manageable” flag is set to “No”… we will NOT put those agents into “Pending Management” for a hotfix (when a SCOM hotfix that should also be delivered to agents is applied to a management server).  This is by design.



Now…. the question is – WHY are there systems with this flag set to NO?

These MIGHT be unavailable to you for a very good reason….  Basically – for ANY agent that was manually installed – and you ever had to “Approve” the agent – we will set Remotely Manageable to No, by design.  The thought process behind this, is that if an agent is manually installed…. we assume it is that way for a reason, and we don’t want to *break* anything by controlling it from the UI moving forward.

Here are some examples of manually installed agents that should NOT be controlled in the UI:

  • AD integrated agents.  If you are using Active Directory integration to assign an agent to specific management servers – you don’t want to ever break this by changing the management server manually, or running a repair, as this will break AD integration.
  • Agents behind a firewall, that cannot be repaired… or that only have ports opened to specific management servers.  If you had multiple management servers, and only allowed a specific agent access to one of them in a firewall – if you manually changed the MS you could orphan the agent.

Now – for most customers I work with – the two issues above don’t apply.  If they do – then DON’T change the Remotely Manageable flag!


However – for many customers, the issues above do not apply…. and they end up with a large number of agents that get this flag inadvertently set to “No”.  They do not desire this behavior.  Here is what can happen to set this flag to No… and when this will be undesirable:

  • Sometimes you will be troubleshooting a (previously) push installed agent – but will delete the agent under “Agent Managed”… and let it re-detect, and then approve it.  SCOM will now treat that agent as manually installed and flag it as such in the database/console.
  • Sometimes you will have a troublesome agent that will not push deploy for some reason, so you manually install/approve a handful of those.
  • Sometimes you are having issues getting an agent to work, and in the troubleshooting process, you manually uninstall/reinstall/approve the agent as a quick fix.

In these cases…. we really need a way to “force” this Remotely Manageable flag back to “Yes” when we understand the issue, and know why it got flagged as “No”….. but desire future ability to repair, uninstall, change MS, and put into pending actions for a hotfix down the road.


Unfortunately – the only way to do that today is via a database edit.  However, it is relatively simple to do.


Below are the queries to better understand this, and modify your agents.  Remember – DON’T do this IF you are using AD integration or have agents that you require to be left alone.


Here is a query just to SEE Agents which are set as manually installed:

select bme.DisplayName from MT_HealthService mths 
INNER JOIN BaseManagedEntity bme on bme.BaseManagedEntityId = mths.BaseManagedEntityId 
where IsManuallyInstalled = 1


Here is a query that will set ALL agents back to Remotely Manageable:

UPDATE MT_HealthService 
SET IsManuallyInstalled=0 
WHERE IsManuallyInstalled=1


Now – the above query will set ALL agents back to “Remotely Manageable = Yes” in the console.  If you want to control it agent by agent – you need to specify it by name here:

UPDATE MT_HealthService 
SET IsManuallyInstalled=0 
WHERE IsManuallyInstalled=1 
AND BaseManagedEntityId IN 
(select BaseManagedEntityID from BaseManagedEntity 
where BaseManagedTypeId = ‘AB4C891F-3359-3FB6-0704-075FBFE36710’ 
AND DisplayName = 


So – I change my agents back to Remotely Manageable…. and refresh my console Agent Managed View…. and voila!  I can now modify the MS, repair, uninstall, etc:




  1. Suganya

    If we have AD integration enabled, what would be the option to make the servers remotely manageable? Could you please let me know. We have to move 100+ servers from MS to newly built GW.

  2. Zikki

    We have used your second query and all servers turned to remotely manageable “YES”. It reduced our work to minutes. Thanks much for your help!
    Any complications would happen if AD integration enabled servers are changed to Yes using the query?

  3. Pingback:SCOM Agent Deployment Troubleshooting - Andrew Blumhardt's Blog

    • Kevin Holman

      No. The product group has stated in the past that changing this flag will not cause any issues. We generally do not support customers editing the database unless under the guidance of a support case. However, if you open a support case on this they will direct you to this blog.


    Hi Kevin, We are planning to update UR10 on SCOM 2016, If I make this to yes, will that have an effect on auto agent failover?

    • Kevin Holman

      This has zero impact on agent failover. This is ONLY to set them to remotely manageable in the console. There is NO other impact.

  5. Trevor

    For our env’t we have admin shares disabled to prevent lateral movement. So having our agents remotely manageable isn’t required. The other snag is that we have DMZ servers so a firewall between them to prevent unauthorized port access. Sometimes two wrongs don’t make a right.

Leave a Reply

Your email address will not be published.