Pages

Oct 29, 2009

here is quite possibly the easiest way i’ve found to sync them up. sometime last year, sysinternals made all of their tools accessible directly from the web. this means no more having to go download the tools. you could launch them or pull them down via live.sysinternals.com.

to go one step further on this bit of information, live.sysinternals.com\tools is directly accessible via explorer, cmd shell, powershell, etc. this is demonstrated as such:

well, now that opens up a variety of different options to sync your copy. explorer would be easiest for drag and drop. if you’re familiar with any of the copy utilities, this should be old hat to you. for me, i favor robocopy in this scenario:

to sync them in the future, you’d run the same command again. just in case you missed it, here it is:

MP Cookdown Analyzer identifies workflows which may break cookdown. Suggestions are provided for how to fix the performance problems.

All References Add-in

All References Add-in helps find all management pack elements that reference the specific element chosen. For example, the ability to right click a class and find all rules, monitors, overrides, as well as anything else that targets that class is provided. This tool works on most management pack elements.

Workflow Analyzer

The Workflow Analyzer provides the ability to statically analyze all types of workflows. It also allows users to trace workflows running on any Health Service.

Workflow Simulator

The Workflow Simulator provides the ability to test certain types of workflows such as discoveries, rules, and monitors without a Management Server and Management Group. Key functionality includes the ability to test workflows as well as view and validate output prior to signing and importing the MP into a Management Group for additional testing.

Management Packs

Three management packs which are frequently used as dependencies are provided as part of the tools installation. These MPs are necessary to allow the Authoring Console to open most MPs available online in the System Center Operations Manager MP Catalog. The provided MPs are:

Oct 21, 2009

another admin pointed out something very odd with this particular monitor. apparently, the monitor has some overrides that change the threshold in certain scenarios. to start, the monitor description:

This monitor ensures that the "Process\Handle Count" counter for the HealthService.exe process does not exceed a set threshold over a series of consecutive samples. If the conditions are met this monitor will change to a critical state, which will then roll up to the "Health Service State" monitor. The "Health Service State" monitor is configured to run a recovery when its state is critical, which will automatically attempt to restart the Health Service.

basically once you breach this number, the health service restarts. this is typically a good thing since you’re keeping it maintained. now, flip to the overrides.

notice that there’s an exchange 2007 computer group override where the value is 5000. try to edit this override. you should get a similar screen.

notice how the value of 5000 doesn’t show up here. interesting that it would even be set at 5000 since 6000 would seem a better rounded number for most agents. so why would the exchange 2007 computer group want a lower threshold? mysterious…

not really -- if you know the history. turns out at one point the threshold was set to some whacky low number. i don’t have a back rev environment to go pull the actual value. let’s just say it was 200. with this value in place, the exchange mp couldn’t reliably operate in large-scale environments with health service constantly restarting. the override value comes from the exchange mp, forcing the threshold count to a much higher, more realistic value.

this makes complete sense except the value is lower than what is shown in the screen shot above, right? actually … the value of 6000 was introduced in the latest operations manager 2007 core mp which was released after the exchange mp.

oh by the way, you’ll see this same behavior in the health service private bytes threshold monitor. (thanks guys!)

Oct 14, 2009

stefan koell of code4ward.net does it again with an update to logsmith. this time, you can see the parameters of the events you’re collecting. very cool gem for opsmgr! get more detail HERE at systemcentercentral.com.

i just ran across this. could be deeply embedded or something or not well advertised. anyway, here’s the navigation path if you want to flush the health service state and cache from an agent via the console.

first of all, navigate to the agent health state view.

[monitoring / operations manager / agent / agent health state ]

you’ll see two panes at this point: agent state from health service watcher and agent state. we only care about the agent state pane. click on the agent that you’re going to send the missile. in your actions pane, you will see “flush health service state and cache”.

Oct 13, 2009

the actual rule name is “Failed to send through device alerting rule” that we’ll be working with. i’m not going to go into length explanations since this is fairly straightforward. just a few things that i wanted to point out (mainly links to good info). basically, this alert has no overrides that are useful. it kept sending out messages that looked like this:

this tends to come up often if the user is not online when the alert is sent through. i suppose you could try to limit the number of times you’d run into this scenario by adjusting the hours that IM is used for alert notification (or not using it at all). i opted to create an identical rule with the right event criteria.

ran logparser and dumped the event so that i could see the exact parameters. it’s detailed HERE on stranger’s blog. the output is separated by pipes. i reformatted it to make it easier to read:

created an identical rule with the following properties (reference HERE for kevin’s blog post if you need more information):

expression -

Event ID equals31503

Event Source equalsHealth Service Modules

Parameter 1 equals$Target/ManagementGroup/Name$

Parameter 5 does not equalsip

response -

Suppression – Parameter 5, 6, 7, 8, 9

now you simply need to disable the original rule and turn this one on (saving it to your own management pack of course). we simply set the event rule to pick up where parameter 5 does not equal sip. by doing this we’ve effectively stopped any alerts on notifications where sip is involved.

Oct 1, 2009

looks like i’m in for another year in the system center operations manager discipline. congratulations to all of the rest of you who are either new or renewed this month.

“Congratulations! We are pleased to present you with the 2009 Microsoft® MVP Award! This award is given to exceptional technical community leaders who actively share their high quality, real world expertise with others. We appreciate your outstanding contributions in System Center Operations Manager technical communities during the past year.”