All posts by Jonathan Almquist

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.

 

The Unleashed book is…well, UNLEASHED!

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

Namespace prefix ‘maml’ is not defined

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">

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

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.

Timed Script Discovery (vbscript)

AKA: Microsoft.Windows.TimedScript.DiscoveryProvider

If you are following these VSAE Fragment posts in order, you’ll see they are tied together in the same example management pack. This fragment demonstrates the timed script discovery provider, and discovers the application component class discussed in the previous post.

What does it do?

This discovery uses a script to read a local csv file (c:\ScomSkills.csv). The file is expected to have two entries, separated by a comma. Doesn’t matter what the entries are, as they will simply be discovered as class properties.

One thing I’d like to callout here is the discovery of Entity\DisplayName, highlighted below. It is important to discover PrincipalName or NetbiosName for Entity\DisplayName, because this is what the source will be when monitors targeting this class generate an alert. Ever see an alert generated by "c:" or "Windows Server 2008"? Not very useful while looking at a long list of alerts in the console, and doesn’t help much if you have other processes that are expecting computer name values for source. This is also discussed here.

 

 

<ManagementPackFragment SchemaVersion="2.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Monitoring>
    <Discoveries>
      <Discovery ID="SCOMskills.Demo.TimedScript.Discovery" ConfirmDelivery="false" Enabled="true" Priority="Normal" Remotable="true" Target="SCOMskills.Demo.LocalApplication.Class">
        <Category>Discovery</Category>
        <DiscoveryTypes>
          <DiscoveryClass TypeID="SCOMskills.Demo.ApplicationComponent.Class">
            <Property TypeID="SCOMskills.Demo.ApplicationComponent.Class" PropertyID="CsvField1"/>
            <Property TypeID="SCOMskills.Demo.ApplicationComponent.Class" PropertyID="CsvField2"/>
            <Property TypeID="System!System.Entity" PropertyID="DisplayName"/>
          </DiscoveryClass>
        </DiscoveryTypes>
        <DataSource ID="DS" TypeID="Windows!Microsoft.Windows.TimedScript.DiscoveryProvider">
          <IntervalSeconds>60</IntervalSeconds>
          <SyncTime/>
          <ScriptName>SCOMskills.Demo.Discovery.vbs</ScriptName>
          <Arguments>$MPElement$ $Target/Id$ $Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$ c:\ScomSkillsDemo.csv</Arguments>
          <ScriptBody>
            <![CDATA[
Option Explicit

Dim oArgs
Set oArgs = WScript.Arguments
if oArgs.Count < 4 Then
   Wscript.Quit -1
End If

Dim SourceID, ManagedEntityId, TargetComputer, SourceFile

SourceId = oArgs(0)
ManagedEntityId = oArgs(1)
TargetComputer = oArgs(2)
SourceFile = oArgs(3)

Dim oAPI, oDiscoveryData, oInst
Set oAPI = CreateObject("MOM.ScriptAPI")
set oDiscoveryData = oAPI.CreateDiscoveryData(0, SourceId, ManagedEntityId)

Dim oFso, oFile, aField
Set oFso = CreateObject("Scripting.FileSystemObject")

If (oFso.FileExists(SourceFile)) Then
Set oFile = oFso.OpenTextFile(SourceFile)
aField = split(oFile.ReadLine,",")

set oInst = oDiscoveryData.CreateClassInstance("$MPElement[Name='SCOMskills.Demo.ApplicationComponent.Class']$")
call oInst.AddProperty("$MPElement[Name='Windows!Microsoft.Windows.Computer']/PrincipalName$", TargetComputer)
call oInst.AddProperty("$MPElement[Name='SCOMskills.Demo.ApplicationComponent.Class']/CsvField1$", aField(0))
call oInst.AddProperty("$MPElement[Name='SCOMskills.Demo.ApplicationComponent.Class']/CsvField2$", aField(1))
call oInst.AddProperty("$MPElement[Name='System!System.Entity']/DisplayName$", TargetComputer)
call oDiscoveryData.AddInstance(oInst)

Else

Wscript.Quit -1

End If

Call oAPI.Return(oDiscoveryData) 
]]>
          </ScriptBody>
          <TimeoutSeconds>30</TimeoutSeconds>
        </DataSource>
      </Discovery>
    </Discoveries>
  </Monitoring>
  <LanguagePacks>
    <LanguagePack ID="ENU" IsDefault="true">
      <DisplayStrings>
        <DisplayString ElementID="SCOMskills.Demo.TimedScript.Discovery">
          <Name>SCOMskills Timed Script Discovery</Name>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
  </LanguagePacks>
</ManagementPackFragment>