You are browsing the archive for 2013 January.

SCOM: excluding items from a group based on hosted roles

5:03 pm in Uncategorized by Jan Van Meirvenne

A customer heavily uses groups to scope access and views to items in SCOM. One of the access-profiles was that for the SQL-team. They can only see the SQL servers they manage along with all objects hosted by those servers. However, SQL server is also a component of TMG, which they do not manage. Because of this they didn’t want to have the TMG servers clutter their clean view on their environment.

The original solution was to statically exclude the TMG-servers. I recommended against this for the following reasons:

– The environment is big and can be volatile, if a TMG server is added it will manually need to be added to the group every time. This requires a lot of maintenance and has a high risk of monitoring-inconsistencies.

– Since there are multiple SCOM management groups, having a management pack with static assignments will break portability. Since most custom management packs are kept in sync across all MG’s, this is a big disadvantage.

I proposed to use an advanced dynamic query that would only populate the group with servers running the SQL-role, but not the TMG one.

In SCOM-XML, you can use the following tags to filter objects in a group query:

Contains: this tag can be used to indicate that objects containing a certain class (for example: Windows Computers that contain a SQL role object) should be selected.

Contained: this tag is the reverse of ‘contains’, it is used to indicate that objects contained within a certain class should be selected (for example: all objects that are hosted in a certain group).

This resulted in the following XML:

<RuleId>$MPElement$</RuleId>
  <GroupInstanceId>$MPElement[Name="Customer.SQL.MP.Group_SQLComputers"]$</GroupInstanceId>
  <MembershipRules>
    <MembershipRule>
      <MonitoringClass>$MPElement[Name="MicrosoftWindowsLibrary!Microsoft.Windows.Computer"]$</MonitoringClass>
      <RelationshipClass>$MPElement[Name="Customer.SQL.MP.Group_SQLComputersRelationShipType"]$</RelationshipClass>
      <Expression>
Add all windows computers to this group that…
        <And>
          <Expression>
…host the SQL server role…
            <Contains maxDepth="1">
              <MonitoringClass>$MPElement[Name="MicrosoftSQLServerLibrary!Microsoft.SQLServer.ServerRole"]$</MonitoringClass>
            </Contains>
          </Expression>
          <Expression>
…AND do not host the TMG role.
            <NotContains maxDepth="1">
              <MonitoringClass>$MPElement[Name="TMG!Microsoft.Forefront.TMG.ServerRole"]$</MonitoringClass>
            </NotContains>
          </Expression>
        </And>
      </Expression>
    </MembershipRule>
    <MembershipRule>
      <MonitoringClass>$MPElement[Name="SystemCenter!Microsoft.SystemCenter.HealthServiceWatcher"]$</MonitoringClass>
      <RelationshipClass>$MPElement[Name="Customer.SQL.MP.Group_SQLComputersRelationShipType"]$</RelationshipClass>
Also add all health service watchers that are hosting a Windows Computer object…
      <Expression>
        <Contains>
          <MonitoringClass>$MPElement[Name="SystemCenter!Microsoft.SystemCenter.HealthService"]$</MonitoringClass>
          <Expression>
            <Contained>
              <MonitoringClass>$MPElement[Name="MicrosoftWindowsLibrary!Microsoft.Windows.Computer"]$</MonitoringClass>
              <Expression>
…and where the hosted computer object was added by the previous membership rule.
                <Contained maxDepth="1">
                  <MonitoringClass>$Target/Id$</MonitoringClass>
                </Contained>
              </Expression>
            </Contained>
          </Expression>
        </Contains>
      </Expression>
    </MembershipRule>
  </MembershipRules>

 

Note that I used the ‘maxDepth’-attribute in the contains- and contained tags. This limits the recursive search of the query, improving performance.

Using advanced group query, selecting a subset from your SCOM-inventory within a group can become very precise and provide a set-and-forget experience!

Write Actions and the workflow simulator: don’t do it

4:44 pm in #scom, #sysctr by Jan Van Meirvenne

I am currently working on a module which combines 2 submodules, which are both write actions (VBS scripts). The reason for this is that one part of the action that needs to be performed needs special credentials, while another part must be run under localsystem.

Special runas-profile WA –> 
                                                          WA
Local System WA->

image

When I attached this to a rule and started a simulation of the workflow, things went haywire:image

Where are my modules? Why doesn’t it show anything but the scheduler-actions?

Well, apparently, this is a limitation of the simulator:

image

Stupid me! But at least I learned something of this!

The workaround for me is to directly perform a trace on the workflow while it is running inside the management group after I imported the management pack. This is slower, but at least it works!

SCOM Troubleshooting: constant high cpu usage of monitoringhost.exe and event 3006

4:36 pm in #scom, #sysctr by Jan Van Meirvenne

 

Symptoms

On a couple of Exchange 2010 servers monitored by Operations Manager, a constantly high CPU usage is reported for the monitoringhost.exe process. Restarting the agent including clearing the cache do not fix the issue. Meanwhile, the application log is being flooded with events with id 3006 and source EvntAgnt.

Solution

The solution is to restart the SNMP service on the affected machine, this will stop the eventlog-flooding and drop the monitoringhost’s CPU usage to normal levels.

The exact same issue and solution where blogged a long time ago by Cameron Fuller for a Server 2003 system, but the issue can apparently also occur on a Server 2008 R2 SP1 machine.