Is your RMS updating configuration too frequently?

re: Is your RMS updating configuration too frequently?

steverac — Fri, 26 Jun 2009 21:00:57 GMT

No, R2/non R2 shouldn't be a factor. My guess is that you are not selecting on the correct database - some of thse are warehouse queries and others are OpsDB queries

re: Is your RMS updating configuration too frequently?

bmwiest — Fri, 26 Jun 2009 19:13:12 GMT

When i run the query here is what I get:

Msg 207, Level 16, State 1, Line 1

Invalid column name 'ManagedEntityTypeSystemName'.

Msg 207, Level 16, State 1, Line 1

Invalid column name 'DiscoverySystemName'.

Is this because I am not running R2?

re: Is your RMS updating configuration too frequently?

steverac — Fri, 12 Jun 2009 02:06:02 GMT

There are definately some areas where we can still make improvements for the 21025. But R2 does make some headway on this. Thanks for your comment and for being a part of the RDP!

re: Is your RMS updating configuration too frequently?

Brandubh — Thu, 11 Jun 2009 19:54:18 GMT

Right now I'm running R2 (we have been part of the RDP), but things are not "so" better. In SP1 every time a property changed the agents would reload (21025) in R2 I don't see such a strict correlation. From your explanation I understand that every time a discovered property changes on an agent I have a 21025 on my RMS? Uhm, if this is the correct behavior we have a bad design. First, the RMS should implement some sort of "quiet" timeout, let's say no more than one reload every x mins (possibly configurable), secondly starting with KB 958490 at every reload on the RMS "unknown state" roll up monitors are asked to recalculate, this will cause a complete reload on agents (without any 21025 event in the eventlog). I will work on this with the product team and follow up with a wrap up post, this point is strategic for the proper behavior of any OpsMgr deployment.

re: Is your RMS updating configuration too frequently?

steverac — Thu, 11 Jun 2009 07:33:02 GMT

An override will cause config churn, approving a pending agent will cause config churn – a single property (like a DB size that adjusts because of autogrow or a temperature reading) will cause config churn. I don’t understand the deep details of why this is the case – but it is. The way I find which attribute is causing the churn is with the second (I think) query on my blog – I think it’s one of your queries. Good show on the queries BTW.

Also, there are improvements for some of this in R2 - not all but some.

re: Is your RMS updating configuration too frequently?

Brandubh — Wed, 10 Jun 2009 11:36:20 GMT

Hi Steve, thanks for the insghts and for cross posting on Quaue Nocent Docent. We all agree frequent changing discoveries are bad, but still, except for new agents and non hosted classes I don't understand the needs of reload on the RMS. I try to reformulate, how can I understand what's causing 21025 on the RMS? My RMS discovery is stale so it is clearly something I get from agents (I have about 20/25 21025 per hour on the RMS). This is the difficult part correlate between somthing that changes on the agent to the RMS. I still didn't find the culprit. On this topic, from my observations, it seems that a change in a MP (say a new override) causes a reload of all the referenced MPs not just the modified one, as you know parsing those XML documents is CPU intensive, I think there's something that can be optimized here. :-)

Steve Rachui's Manageability blog - ConfigMgr/OpsMgr : Understanding ???nested??? management pack discoveries and how they impact total discovery time?

Tue, 09 Jun 2009 19:33:43 GMT

PingBack from http://blogs.msdn.com/steverac/archive/2009/06/09/understanding-nested-management-pack-discoveries-and-how-does-they-impact-total-discovery-time.aspx