Posts in this blog are provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified in the Terms of UseAre you interested in having a dedicated engineer that will be your Mic

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

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:

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 = 'agentname.domain.com')

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:

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!

Graham Davies

22 Feb 2010 11:24 PM

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

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.

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

Jason Schuster

5 Mar 2010 3:29 AM

Thanks Kevin,

This is very Useful..

thanks

Jason

Dominique

14 Mar 2010 5:41 AM

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?

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'.

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.

David

14 Feb 2011 9:51 AM

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.

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)

Josh Shand

1 Jul 2011 1:29 AM

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

Venkat

13 Feb 2012 2:51 PM

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?