Monthly Archives: March 2013

Authoring, Buggy

Logical Disk Free Space monitor doesn’t cookdown

Leave a comment

I haven’t looked at the internals of this monitor in a long time. But recently I was working on a modified disk free space monitoring solution for a customer, and to my surprise uncovered the fact that the built-in logical disk space monitor in the Windows management packs do not utilize cookdown. This had changed at some point in time, because I know these monitors  took advantage of cookdown in previous versions.

Fixing this wasn’t officially a part of the disk monitoring project I was tasked with, but just knowing the fact it didn’t utilize cookdown was enough to compel me to rewrite the entire workflow. After I fixed the cookdown problem and finished other additions to the disk space monitor, I was going to post a management pack here with an updated logical disk free space monitor…until I stumbled across a blog entry Kevin Holman posted over a year ago.

I’m not sure if Kevin realized at the time that his addendum MP fixed the cookdown problem, but it does. Hot smile Head over to his blog to download the addendum MP, especially if your company uses a lot of instance level disk space overrides.

 

For those that need a refresher on cookdown, this is a programming technique that (if implemented properly) will execute only one instance of a script data source even if there are multiple monitoring instances that consume the output. The key to cookdown is passing no (or only necessary) configuration elements into the script execution, and processing instance and state filtering after script execution by using expression filters.

If the script expects configuration input, and the monitor configuration is changed by an override, the script will need to run once for each instance override. In the case of the logical disk free space monitor, this leaves a huge door of opportunity to run multiple copies of the data source script, and this will lead to resource consumption on the monitored computer.

 

The built-in logical disk free space data source module (cookdown broken with overrides)

 

<DataSourceModuleType ID="Microsoft.Windows.Server.2008.FreeSpace.Moduletype" Accessibility="Internal" Batching="false">
  <Configuration>
    <xsd:element minOccurs="1" name="ComputerName" type="xsd:string" />
    <xsd:element minOccurs="1" name="DiskLabel" type="xsd:string" />
    <xsd:element minOccurs="1" name="IntervalSeconds" type="xsd:integer" />
    <xsd:element minOccurs="1" name="SystemDriveWarningMBytesThreshold" type="xsd:double" />
    <xsd:element minOccurs="1" name="SystemDriveWarningPercentThreshold" type="xsd:double" />
    <xsd:element minOccurs="1" name="SystemDriveErrorMBytesThreshold" type="xsd:double" />
    <xsd:element minOccurs="1" name="SystemDriveErrorPercentThreshold" type="xsd:double" />
    <xsd:element minOccurs="1" name="NonSystemDriveWarningMBytesThreshold" type="xsd:double" />
    <xsd:element minOccurs="1" name="NonSystemDriveWarningPercentThreshold" type="xsd:double" />
    <xsd:element minOccurs="1" name="NonSystemDriveErrorMBytesThreshold" type="xsd:double" />
    <xsd:element minOccurs="1" name="NonSystemDriveErrorPercentThreshold" type="xsd:double" />
  </Configuration>
  <OverrideableParameters>
    <OverrideableParameter ID="Interval" Selector="$Config/IntervalSeconds$" ParameterType="int" />
    <OverrideableParameter ID="SystemDriveWarningMBytesThreshold" Selector="$Config/SystemDriveWarningMBytesThreshold$" ParameterType="double" />
    <OverrideableParameter ID="SystemDriveWarningPercentThreshold" Selector="$Config/SystemDriveWarningPercentThreshold$" ParameterType="double" />
    <OverrideableParameter ID="SystemDriveErrorMBytesThreshold" Selector="$Config/SystemDriveErrorMBytesThreshold$" ParameterType="double" />
    <OverrideableParameter ID="SystemDriveErrorPercentThreshold" Selector="$Config/SystemDriveErrorPercentThreshold$" ParameterType="double" />
    <OverrideableParameter ID="NonSystemDriveWarningMBytesThreshold" Selector="$Config/NonSystemDriveWarningMBytesThreshold$" ParameterType="double" />
    <OverrideableParameter ID="NonSystemDriveWarningPercentThreshold" Selector="$Config/NonSystemDriveWarningPercentThreshold$" ParameterType="double" />
    <OverrideableParameter ID="NonSystemDriveErrorMBytesThreshold" Selector="$Config/NonSystemDriveErrorMBytesThreshold$" ParameterType="double" />
    <OverrideableParameter ID="NonSystemDriveErrorPercentThreshold" Selector="$Config/NonSystemDriveErrorPercentThreshold$" ParameterType="double" />
  </OverrideableParameters>

 

The proper way to implement a script data source to utilize cookdown (configuration and state filtering should happen at the monitor type, not the data source module)

 

<DataSourceModuleType ID="Microsoft.Windows.Server.2008.Monitoring.Addendum.FreeSpace.ModuleType" Accessibility="Internal" Batching="false">
  <Configuration>
    <xsd:element minOccurs="1" name="IntervalSeconds" type="xsd:int" />
    <xsd:element minOccurs="1" name="TargetComputerName" type="xsd:string" />
  </Configuration>

 

I wonder if Microsoft will plan to fix this in the future. Good thing these modules are flagged internal, so it shouldn’t be much to ask and an update wouldn’t break upgrade compatibility for customers.

This post applies to Windows MP versions 6.0.6958 – 6.0.6989.0.

_

Buggy

Health Explorer – Scope is only unhealthy child monitors

Leave a comment

This is misleading, as it’s only true sometimes. Let me show you a clear example with pictures.

 

The examples below can be reproduced with OpsMgr 2012 SP1 by opening Health Explorer for the Windows Computer object.

Example 1

Two unhealthy instances; one critical and the other warning.

Health Explorer default behavior

Instance in warning state isn’t listed with the filter applied.

image

 

Remove the unhealthy filter

Instance in warning state is listed when filter is removed (as expected).

image

 

Example 2

Two unhealthy instances; both critical.

Health Explorer default behavior

Both critical instances are listed.

image.

 

Remove the unhealthy filter

Both critical instances are listed (as expected).

image

 

Example 2

Two unhealthy instances; both warning.

Health Explorer default behavior

Both warning instances are listed. Also notice that HEALTHY instances of the SAME TYPE are also listed.

image

 

Remove the unhealthy filter

Both warning instances are listed, as well as everything else (as expected).

image

 

The main takeaway with this post is to beware of the default behavior in Health Explorer – it might only show you half the truth. I’m not sure if I’d go as far as lodging a bug or calling into Microsoft support services for this, but I certainly didn’t’ expect this behavior with the filtering option.

 

Projects

The Unleashed book is…well, UNLEASHED!

Leave a comment

When I was asked to contribute to this book, I didn’t hesitate at the opportunity to be a part of what is considered to be the most comprehensive technical resource for System Center engineers and enthusiasts around the world. This is the first official publication I’ve been involved in, and am proud to have had the opportunity to share my experiences at this level.

I hope the community receives this book well, and that this edition lives up to its reputation! Thanks to Kerrie Meyler, Cameron Fuller, and John Joyner for doing such a great job in supporting the contributors and to keep things moving along.

 

Unleashed

 

Unleashed_2

VSAE Errors

Namespace prefix ‘maml’ is not defined

Leave a comment

If you include knowledge articles in your management pack and fail to reference the maml schema, you’ll see this error during build time.

 

Error      80           Namespace prefix 'maml' is not defined

 

clip_image002

 

It’s a very easy fix. Simply add the highlighted below to the management pack fragment and build away.

<ManagementPackFragment SchemaVersion="2.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:maml="http://schemas.microsoft.com/maml/2004/10">

Cross-Platform

Dual-Home Unix/Linux Agent (multi-home)

Leave a comment

I ran into this request recently, but couldn’t find any official documentation on this. I’m sure this information is out there somewhere, but figured it’s a 2 minute post so here it is.

Turns out it’s actually quite easy, as long as you have your certificates lined up.

You’ll need to have all SCX certificates from every management server installed on every other management server that participates in a cross-platform resource pool. In other words, a complete certificate mesh between all multi-homed management groups!

Simply login to a management server that is a member of the cross-platform resource pool in the original management group, open a command prompt as administrator, navigate to %Program Files%\System Center\Operations Manager 2012\Server folder, and execute the following command:

scxcertconfig.exe -export xplat.cert

 

 

Next, copy that exported cert file to the same folder on each management server in the cross-platform resource pool in the second management group. Then import it by running the following command:

scxcertconfig.exe -import xplat.cert

 

Now you can run discovery/installation. The news is, no certificate signing or agent installation needs to happen, so it’s a very quick operation going forward.