How to get your agents back to “Remotely Manageable” in OpsMgr 2007 R2


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:



Comments (55)

  1. Kevin Holman says:

    @ Mohammad

    The agents will not go into pending now…  this is a one-time action that is performed at the time of applying a CU on the management server.  Agents will never "pop into pending" at a later time once they meet the criteria.

    If you need to update agents with a CU, and they are not in pending for the update, simply run a "repair" on them.

  2. Kevin Holman says:

    Venkat – I clearly address that in the above blog post.  If you are using AD integration, you should not modify this setting.  It will break AD integration.

  3. Kevin Holman says:

    Console can't do it, but Powershell can

  4. Kevin Holman says:

    @Phil –

    If you are using AD integration, you would generally not want to change this setting. If using AD integration, you don’t use the console to assign management servers, you use AD integration rules. However, it is plausible that you want to use AD integration,
    but want remotely manageable set to true, so you can easily apply/push agent upgrades via the console.

    If that isn’t required, and you will also use group policy to push out the agent updates, then I’d not change the setting.

    Editing the SQL database is not supported by Microsoft. You wont ever get a "support statement" on this, other than "unsupported". However, for customers who understand the issue, and understand why they need remotely manageable = true, this is a very safe
    modification to make.

    1. Hi Kevin! Is it really unsupported from Microsoft to convert manually installed OpsMgr agents to “Remote Manageable” by changing “IsManuallyInstalled” against the operational DB. Only against agents that should have been installed through SCOMs “Discovery”.

    2. Is it more supported and easier to install UR for agents through Windows Update or push it through SCCM? If we do this on all agents will the “discovey” agents be change to “manaully”?

      //Mats A

  5. Phil Marcum says:

    Hey sir thanks for taking the time to respond, again. Yes the dev_scom_HSvcSCP_SG container along with Domain Local security groups and containers for each of the management servers were created during the ADI setup. In terms of reference materials I have
    SCOM 2012 Unleashed 2nd edition and just about all of the known articles in terms of configuring ADI per a documented procedure. So I’m thinking I’ve overlooked some minor detail in terms of getting this to work.

    In viewing a reference site I see mention of a rule called AD rule for Domain. I have version 7.1.10226.0 of the Default management pack installed and when performing a search for this rule I see an AD rule for Domain:, ManagementServer: domainms
    but I don’t see the rule displaying polling info. Again not sure what I’m missing.

  6. Phil Marcum says:

    dang it! replied to the wrong thread/post. Please delete if possible.

  7. Kevin Holman says:

    @Jarrad –

    What do you mean "internet based" ?  Do they connect via direct internet with a direct management server open to the public internet (gasp).  Or do they connect via a VPN tunnel and then are managed alike a remote WAN agent on the corp network?

    In either case, it doesnt really matter.  The benefit of not locking them down as a "manually installed" agent is that we will try to update them when you apply CU's, and you have the option to attempt a repair.  If you dont have full RPC/SMB open to manage the agent, then it is an irrellevant conversation.

  8. Marius Ene says:

    Do these settings also apply to scom 2012?

  9. Kevin Holman says:

    Yes Ramesh – that is basically one of the key points of this post – for that ability right there.

  10. Phil Marcum says:

    Is this thread still "Live"? I came across this while searching for a SCOM 2012 R2 agent deployment strategy. In my setup I have separate DEV and a PROD SCOM 2012 R2 environments in addition to a 2012 SP1 environment. Active Directory Integration seems
    to make sense as I want to automate the new 2012 R2 agent installation via group policy, which is still considered a manual installation.

    Based on the first question in this post it looks as though one can still have Active Directory Integration and the option to manage the clients by changing the flag in the database. Although it goes against Microsofts’ design strategy the question is does
    it violate any Microsoft support agreements? Is there any reference to this for SCOM 2012 R2 within Microsoft’s website or do I have to contact support for validation?

    Any responses appreciated.

  11. Kevin Holman says:

    No, you arent missing anything – SP1 had a bug where this didnt work and block access in the console as it should.  It was "fixed" in R2.

  12. Kevin Holman says:

    @David –

    This is the setting, that the hotfix installer will use to determine the agent should be placed into pending.  Therefore – the answer is yes – if this is set to "Yes" then when you apply a hotfix to a Management server that has directly assigned agents – they should now go into pending management for an update.  If you approve it – it will work, provided the account you use has permissions, and the firewall ports are open.  (same as agent push)

  13. Kevin Holman says:

    @Marlon – in general – Microsoft does not support direct edits to the databases of products, unless directed by a support person while under an open support case. That said – the product group has stated this specific change should be fine and should not
    have any ill circumstances. MOST companies I know and work with edit this on a regular basis.

    For DMZ servers – generally you should not place any MS in a DMZ, you should consider a gateway server for use in the DMZ. The gateway will have a cert, and it’s assigned upstream management server should have a cert. It is a good idea to allow multiple management
    servers to have certs, and configure your GW’s to be able to fail over to another management server when needed, for higher availability.

  14. Kevin Holman says:

    @Jonathan – the SCSM agents are "special" and should not be updated nor patched/moved or treated as remotely manageable.

  15. Kevin Holman says:

    @AFL – Yes. It is applicable to SCOM 2012.

  16. Ramesh says:

    Kevin – After we install the agents manually on servers (behind firewall, workgroup) and if we set those agents to “Remotely Manageable = Yes” using the query as you suggested, we’ll be able to control those agents from the UI alike those which are pushed from the console – right? Also if MS releases hotfixes/updates applicable for R2 agent, then those will appear in the pending management node to ease our administration – right?

    I just wanted to get it confirmed that after we run the query that will set ALL manually agents back to “Remotely Manageable = Yes”, then they will become similar to the pushed agents on all aspects!

  17. Hi Ramesh

    Updating the table by itself will not be enough – be aware that you’ll still need to open the relevant ports to enable the updates to take place. If these manually installed agents are behind a firewall then making them "remotely manageable" won’t magically enable them to receive updates if the firewall won’t pass the traffic. And you won’t get your security teams to open the Netbios ports required for push install ….



  18. Ramesh says:

    Thanks Graham – I understand that we won’t be able to push future updates on agents behind firewall if the ports are not open, but they will appear in the ‘pending management’ mode – right?

    What we are basically seeking is to assign the SCOM agent installation task on all servers to our L1 helpdesk who will install the agents manually and then we’ll run this SQL query to make them ‘Remotely Manageable=Yes’. So in case of future updates from MS for R2 agent, all of them will appear in the ‘Pending Management’ node and whichever do fail while approving from the console we’ll update them manually.



  19. Jason Schuster says:

    Thanks Kevin,

    This is very Useful..



  20. Dominique says:

    Hi Kevin,

    This is working for the test machines I tried. I would like to know what exactly you consider "AD Integration"? is it the fact that the discovery is done through AD? Is it the fact that all machines are in AD domain? Is it something else?



  21. hello says:

    We have several manually installed agents in our SCOM 2007 SP1 environment.  What I find stranges is that even the manually installed agents appear to be 'Remotely Manageable = Yes', as oppposed to 'IsManuallyInstalled = Yes'.

    Am I missing something?



  22. Mohammad Damati says:


    we downloaded and installed SCOM 2007 R2 CU3, later we applied the SQL Query to change Remotely managed for some servers to yes.

    till now the Agents are not showing in Pending Management in order to approve the update, is there any further action required?


  23. David says:

    Hi Kevin,

    I have 4000+ servers that have manually installed agents on R2CU2 that now have Remotely Managed = "Yes" via the SQL Script.  The question that keeps getting mixed answers is when CU4 is applied to the OPSmgr Infrastructure will the agents now come into pending allowing me to upgrade all these manually installed agents that now have the Remotely Managed flag set to Yes.  This is assuming all firewall ports are open etc.  I keep getting different answers on this question and would like to know since the intention is to have all 4000+ agents come into pending and then phase these updates in groups during off hours.  These agents have not been repaired just the Remotely Managed set to Yes.  Thanks.

  24. Josh Shand says:

    Hi Kevin,

    I know this was covered a while ago, hopefully you are still aware of comments!

    Am I to understand by the comment:

    "***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."

    That if we DO use the script to change all our agents to be remotely manageable that they should EVENTUALLY show up in Pending Management as needing an update after running a CU?

    Kind Regards

  25. Venkat says:

    Hi Kevin,

    We have SCOM 2007 R2 envi and i am planning for CU5 update installation. We have few of agents that are not remotely manageble (manually installed). If i change them to remotely manageble agents using the sql query provided will my AD Integration breaks? if it is broken, can i dele that and put it back in place using momoadadmin.exe?


  26. Ivan Kristensen says:

    It would be very nice, if the agent were able to download updates via the already opened standard ports, through the firewalls. Netbios is not an option, and now we have to make an sccm package………

  27. Jarrad says:

    Hi Kevin,

    Is this still the case for SCOM 2012?



  28. Jarrad says:

    Thanks Kevin.

    Another question. Would you recommend this for internet based managed agents?

  29. Jarrad says:

    Hi Kevin,

    I meant internet based just like in Config Manager, agents connecting via the internet. Don't worry this customer is using certs, gateway servers, firewalls, dedicated AD and Ops Mgr infrastructure isolated just for this, port redirects… etc. But I stupidly did not think about the UDP ports needed!!!

  30. pete says:

    I'm a little confused by this, since we have a script that load balances the Agents between MS every month. Most of the Agents are manually installed, and some are pushed out from the console. According to this, we shouldn't be able to run the script successfully since the manual Agents should ignore it. We run R2 CU5 (now CU6) and it works fine.

    So is this a case of "Console can't do it, but Powershell can" or is it the script is specifically written to circumvent the issue?


    $arrServerObject = @()

    $arrAgentObject = @()

    foreach($Server in $CSVServerList)


    $arrServerObject += Get-ManagementServer | where {$_.Name -eq $Server}

    echo "Looking for $Server"


    $ServerCount = $arrServerObject.Count

    if ($ServerCount -gt 1)


    echo "Found $ServerCount management servers"

    } else {

    echo "Found only 1 (or less) management servers. Aborting…"



    echo "Getting agents…"

    foreach ($Server in $arrServerObject)


    $arrAgentObject += Get-Agent | where {$_.PrimaryManagementServerName -eq $Server.Name}


    $AgentCount = $arrAgentObject.Count

    if ($AgentCount -gt 1)


    echo "Found $AgentCount agents"

    Start-Sleep -m 200

    } else {

    echo "Found only 1 (or less) agents. Aborting…"



    $i = 0

    foreach ($Agent in $arrAgentObject)


    if ($i -ge $ServerCount)


    $i = 0


    $arrTemp = @($arrServerObject | Where-Object {$_ -ne $arrServerObject[$i]})

    # $FailoverServers = $arrTemp -join ","

    Set-ManagementServer -AgentManagedComputer: $Agent -PrimaryManagementServer: $arrServerObject[$i] -FailoverServer: $arrTemp

    $arrTemp = $null



  31. jim says:


    I just tried this on my scom 2012 infrastructure and works great. Took a minute for the console to update, so give it some time.


  32. Neil says:

    I've just run this on SCOM 2007 and although the agent is now remotely manageable, the option to change primary management server is still not available.

  33. David says:

    Hi Kevin,

    Now we are planning to do scom 2012 upgrade from scom 2007 r2 and enabled AD integration . therefore we need to move the agents to another MG server. In this case can you explain how to move the AD integrated agents to another management server

    Thanks in Advance

  34. Manny says:

    I'm guessing this procedure is safe to use on SCOM 2012 if the QUERY returns a correct list of agents…but I can I get some confirmation that it is?

    I can't see the GUID changing for 'BaseManagedTypeId' – but stranger things have happened.

  35. Garry Trinder says:

    Hi Kevin,

    can i use this to break AD Integration? We don't won't to use AD Integration any longer. My idea is to run the script, remove Container in AD, apply CU4 to SCOM so that all Agents will be shown under pending management, update the Agents through the console. I think this should work, or not?

    I think this is better than uninstall all Agents and then reinstall via console.



  36. Kevin Holman says:

    @Klaus –

    Interesting concept.  I don't know.  Have to test it.  There is a registry entry for agents that let them know they are AD integrated vs manual configuration.  This might work as you desire, but I'd have to test and observe.

  37. Garry Trinder says:

    Hi Kevin,

    thanks for your answer. I've tested this and it works. :-)!



  38. Clive Adams says:

    Hi Kevin, will the correct use of the scripts for the purposes described in this article void any Microsoft support agreement?

  39. Aaron Jones says:

    So I have tested this process on a few servers. (We’re moving away from AD integration and moving some servers to gateway servers) After I’ve run the query against the database it shows as remotely manageable and repair and uninstall are available, but
    change primary management server is still greyed out.

    Any thoughts on this?

  40. Aaron Jones says:

    I should have mentioned I am on 2012 R2…

  41. richa says:

    Hi Kevin,

    Could you assist me how can i upgrade SCOM 2007 R2 agent into SCOM 2012 R2 agent. I could not get any idea properly.


  42. Horacio says:


  43. Nithin KG says:

    We have SCOM 2012 R2 in our envirnment.
    Our clients have shared a list of servers and it’s big list to do by hand.
    I need to write an sql querry which determine which all have SCOM agent installed and which all have not .
    Can anyone help me on this?

  44. Jonathan says:

    Are there any issues with updating SCOM agents on SCSM server (SC R2) to "remotely manageable"?

  45. Jonathan says:

    Thanks for the quick response!

  46. Marlon says:

    Hi Kevin,

    This is a great information and very helpful. I am now exploring Tao Yang’s MP (OpsMgr Self Maintenance MP) and we (our team) are not sure if this direct changes on the database will void the warranty?

    Also, for DMZ servers, do we need to add certificates on all MS? and open all ports?

    Thank you for the response.


  47. AFL says:

    Hi Kevin,

    Is this fix applicable in SCOM 2012 R2?


  48. Vishvajit says:

    My requirements are, I need to do remotely manageable = ‘yes’ for selected agents, like out of 1000 only 200, as this 200 servers are reporting to a gateway server which I need to move to another gateway server….but as per your script either all or 1
    server can be set to ‘yes’. can there be any modification done, which can fulfill my requirements??

  49. Anonymous says:

    This is my final article in a 3 part series about Alert Management. Part 1 is here . Part 2 is here

  50. Graham says:

    Thanks Kevin this worked for me

  51. Tadgata says:

    Thanks Kevin for the wonderful explanation.