Kevin Holman's System Center Blog

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

  • Comments 42
  • Likes

 

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:

image

 

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”

image

 

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

 

image

 

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

 

image

 

***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 = '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:

 

image

Comments
  • @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.

  • Hi Kevin,

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

    BR

    Klaus

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

  • 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?

  • I should have mentioned I am on 2012 R2...

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

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

  • 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: mydomain.com, ManagementServer: domain\ms but I don't see the rule displaying polling info. Again not sure what I'm missing.

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

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

    Thanks
    Richa.

  • Excelente.

  • 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?

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
Search Blogs