Category Archives: Buggy

Logical Disk Free Space monitor doesn’t cookdown

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.

_

Health Explorer – Scope is only unhealthy child monitors

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.

 

Data warehouse configuration failed to install

Had a problem today installing an additional management server using the installation wizard. Installation stopped and rolled back at the Data Warehouse Configuration step (Data warehouse configuration failed to install).

image

I didn’t see anything too unusual in the logs, so it was a bit confusing. I asked Boklyn Wong (MCS) to check into the problem, and he discovered that there is sometimes an issue with the installation wizard when using non-standard database ports (which we are). He suggested I attempt to install via command line, and this worked for us.

setup.exe /silent /install /components:OMServer /SqlServerInstance: <server\instance> /SqlInstancePort: <port> /DatabaseName: OperationsManager /DWSqlServerInstance: <server\instance> /DWSqlInstancePort: <port> /DWDatabaseName:OperationsManagerDW /ActionAccountUser: <domain\account> /ActionAccountPassword: <password> /DASAccountUser: <domain\account> /DASAccountPassword: <password> /DataReaderUser: <domain\account> /DataReaderPassword: <password> /DataWriterUser: <domain\account> /DataWriterPassword: <password> /EnableErrorReporting: Always /SendCEIPReports: 0 /UseMicrosoftUpdate: 0

 

Only problem is there doesn’t appear to be an installation path switch, so if you’re installing to anywhere but the default c:\program files, you may need to search a little more for the installation path switch.

Reference: http://technet.microsoft.com/en-us/library/hh416216.aspx

Service Principal Name Configuration Status – SQL Server cannot authenticate using Kerberos

Marnix did a post on this a while back, but I wanted to supplement what he wrote with some additional information.

If your SQL Service account exists in another domain, this monitor will not work because line 597 of the data source script queries LDAP instead of GC.

Set oRootDse = GetObject(“LDAP://RootDSE”) should be Set oRootDse = GetObject(“GC://RootDSE”)

If you are affected by this issue, you’ll need to fix the script – which means rewriting the monitor.