Archive

Archive for the ‘Concepts’ Category

Alerts that are raised by the monitors should not be manually resolved in Operations Manager 2007

April 21, 2010 Leave a comment

A recent KB Article which discusses Alert Management with Monitors Best Practice – http://support.microsoft.com/kb/979388

Advertisements

OpsMgr Queues

August 25, 2009 Leave a comment

A good explanation came up today on the technet forums about the OpsMgr queues. The answer was provided by Hui Wang:

1: OpsMgr uses 1 ESE DB to store all data sent from the agent, this ESE DB is called “Health Service Store” DB. It’s normally under “\Health Service State\Health Service Store”, you will see several files under this directory, all these files are for that “Health Service Store” ESE DB.
Within this ESE DB, not only queues are in it, workflows also store state in it.

2. When agent loses communication with the mangement server, “Health Service Store” will start to grow because of the Queue within it is backing up. To check the size of the queue you can check performance counter “Health Service Management Groups(*)\Send Queue % Used”” and “Health Service Management Groups(*)\Send Queue Size”.

3. Not sure I understand what do u mean by limit the growth, the queue will grow when local workflow is running and collecting data but agent is not connected to MS. Unless you disable workflow, the queue will grow untill agent is conneted to MS. There is a registry setting u can use to set the maximum queue size limit.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HealthService\Parameters\Management Groups\\MaximumQueueSizeKb

4. When queue is full, it will groom data according to “delete priority” and then “age” of the data in the queue, the idea is less important and old data gets groomed first.

Categories: Concepts, Queues

Overrides

August 2, 2009 Leave a comment

Best Practice:
http://support.microsoft.com/default.aspx/kb/943239

Cory Delamatar from Microsoft gave this excellent explanation about overrides – “Yes, this is a Best Practice. Create a new MP to store overrides for each logical grouping of MP’s. So, if you Import the three SQL 2005 MP’s, I’d create a new MP called SQL 2005 Overrides. Any Overrides you create that are targeted at SQL 2005 types, you should store them in that overrides MP you created.

The reason for this is that every time you create and save an override, that changes the MP that you stored it in. If the MP contains overrides (or anything else really) that’s targeted at something that every agent has (Windows.Computer for example) then that MP is going to get re-downloaded to every agent that has at least 1 instance of that type. So, if you save an Override for a SQL Database and store it into the Default Management Pack, that’s going to cause every agent in your environment to request a new copy
of the Default Management Pack. Now, if you were to save that SQL Database override into an MP that only has SQL Server stuff it in, then only the SQL Server agents will request a copy of that MP.

Bottom line, lots of small and highly targeted MP’s are better than the
single monolithic Default MP with every override in it.”

A poster called Rule and Monitor Targeting Best Practices is available in pdf format at:
http://go.microsoft.com/fwlink/?LinkId=125048

Probably the easiest way to list overrides is via the Override Report (part of the generic reports library). Microsoft have a training video on how to do this here:
http://www.microsoft.com/winme/0712/31678/OverrideReports_300kbps.asx

You can also user powershell:
get-managementpack | get-override | format-list name,parameter,value

You can also see the overrides in the Authoring Pane on Operations Manager 2007 R2 although the scope only really works if the override is targetted at a specific class. If it is targetted at a group then only “group” is specified, not the actual group.

Kevin Holman also posted this on the technet forums if SQL is your preferred scripting solution:

select rv.DisplayName as WorkFlowName, OverrideName, mo.Value as OverrideValue,
mt.TypeName as OverrideScope, bme.DisplayName as InstanceName, bme.Path as InstancePath,
mpv.DisplayName as ORMPName, mo.LastModified as LastModified
from ModuleOverride mo
inner join managementpackview mpv on mpv.Id = mo.ManagementPackId
inner join ruleview rv on rv.Id = mo.ParentId
inner join ManagedType mt on mt.managedtypeid = mo.TypeContext
left join BaseManagedEntity bme on bme.BaseManagedEntityId = mo.InstanceContext
Where mpv.Sealed = 0
UNION ALL
select mv.DisplayName as WorkFlowName, OverrideName, mto.Value as OverrideValue,
mt.TypeName as OverrideScope, bme.DisplayName as InstanceName, bme.Path as InstancePath,
mpv.DisplayName as ORMPName, mto.LastModified as LastModified
from MonitorOverride mto
inner join managementpackview mpv on mpv.Id = mto.ManagementPackId
inner join monitorview mv on mv.Id = mto.MonitorId
inner join ManagedType mt on mt.managedtypeid = mto.TypeContext
left join BaseManagedEntity bme on bme.BaseManagedEntityId = mto.InstanceContext
Where mpv.Sealed = 0
Order By mpv.DisplayName


In the GUI, you can only set one override at a time but Boris has released a Bulk Override Tool into the wild:
http://blogs.msdn.com/boris_yanushpolsky/archive/2007/08/04/disabling-enabling-multiple-rules-monitors-discoveries-at-once.aspx

Rules and Monitors

July 10, 2009 Leave a comment

Here is a great explanation of rules and monitors and how they fit into the scheme of Operations Manager functionality.
http://technet.microsoft.com/en-us/library/bb977440.aspx

Targetting

July 10, 2009 Leave a comment

targetting is generally done for 2 reasons:
– creating new rules and monitors
– overrides existing rules and monitors

For custom rules \ monitors I generally:
– create the rule \ monitor disabled
– create a group of objects that will be monitored
– set an overide enable against the group
– remember not to target the group directly (http://blogs.technet.com/brianwren/archive/2007/08/22/targeting-rules-and-monitors.aspx)

One tool that I find invaluable in assisting with this is the effective configuration viewer (This will tell you whether the rule \ monitor actually hit the agent …. which is always a good first step):
http://www.microsoft.com/downloads/details.aspx?FamilyID=A9DB4DCA-6716-478D-89B9-42F27EBC76A8&displaylang=en

To get more involved with this you can use the Authoring Console to create classes and target more effectively that way …. it just depends how deeply you want to get involved in the authoring.
http://technet.microsoft.com/en-us/magazine/2008.11.targeting.aspx?pr=blog

For targeting overrides – when you go to set the override you will get a list of objects to target … even if I set this to a group I’ll make sure the group contains the objects that are listed as other options on the override.

Also check out the following:
http://support.microsoft.com/default.aspx/kb/943239
http://download.microsoft.com/download/f/a/7/fa73e146-ab8a-4002-9311-bfe69a570d28/BestPractices_Rule_Monitor_REV_110607.pdf