PKI certificates are used to provide SSL encryption for web sites, to secure cross-server traffic (for example to join security gateways or agents in untrusted domains on OpsMgr), to guarantee the identity of the sender of a message and so on. What all certificates have in common is that their destiny often means to be forgotten after having been requested and installed. Until a certificate becomes invalid that was vital to a service. Mostly because it has expired.

To avoid service interruptions or embarrassment due to SSL warning messages displayed to users, the PKI Certificate Verification Management Pack was born. It discovers certificates and certificate revocation lists stored locally on computers and alerts you when:

  – a certificate’s lifetime is about to expire (by default 21 days in advance)
  – a certificate’s lifetime has ended
  – a certificate has become invalid because of a different reason
  – a CRL has not been updated in a timely manner

The MP also includes a series of inventory reports, which help keeping up with all those certificates in your environment. You will find more details in the comprehensive MP guide.

Certificate Verification Screen Shot

Download

The MP and the guide are available for download at the SystemCenterCentral.com site:

Download from SystemCenterCentral.com MP Catalog

I wrote the MP in close collaboration with Pete Zerger and Jaime Correia of the SCC community. Without their help and the support of everyone testing the MP, it wouldn’t be here today.

MP Creation Zen

And there’s more! For everyone interested in learning how to author MPs: Have a look at the 6 part series MP Creation Zen. The articles will walk you through the process of writing an MP, carefully clarifying everything you need to know. Whenever possible, all authoring examples are explained using the new and much improved OpsMgr 2007 R2 Authoring Console, telling you how the PKI Certificate Verification MP was written. I recommend the documents to everyone planning to write a Management Pack by themselves without being application developers.

I have just uploaded an update to the Scheduled Task Management Pack. Under certain circumstances the discovery of Windows 2003 tasks failed. The new version 1.1.1.1 fixes the bug in the discovery script.

I do recommend everyone who is currently using version 1.1.1.0 to upgrade to 1.1.1.1. Simply download the new version here and update the management pack by importing Custom.Windows.TaskScheduler.Windows2003.Monitoring.mp.

Many thanks to Aengus and Mark for making me aware of this bug.

Having thought about enabling the Scheduled Task Management Pack for non English operating system versions for some time, I finally found the time to update it. The new release (Version 1.1.1.0) works with the following OS languages:

The update is available here: Scheduled Task Management Pack understands 7 languages.

The reason why only 7 languages are currently supported on Server 2003 is that in order to discover and manage the tasks, the output of the ’schtasks.exe’ command needs to be parsed. That output unfortunately varies between different languages. I decided to include support for those languages I have at least a basic knowledge of (very basic for 3 of them). If you need other languages to be added let me know.

Like a little language quiz? Here’s what Scheduled Tasks are called on other OS languages. Can you tell which expression is in what language?

tareas programadas / geplande taken / operazione pianificata / tâche planifiée  / tarefas agendadas / geplante Tasks

On Windows Server 2008 parsing ’schtasks.exe’ is not required as Microsoft has included COM object with the OS that allows managing the tasks using scripts and that is language independent.

Many thanks to Romain Girot who’s helped a lot by testing the localization support accurately and patiently.

Summary

Over the last few weeks the Multi-Host Ping Management Pack developed as a joint work by the System Center Community has seen a major update from version 2.0 to 3.0. The new Management Pack is class based and represents the health of each Ping Target (address being pinged)  as seen by one or more Ping Watchers (agent issuing the ping).

Great care has been taken to increase the scalability and keep the performance impact on the Ping Watchers low. Other than the discovery process, all datasources rely on native Operations Manager modules instead of VBScripts. Furthermore all monitors and rules of the management pack incorporate ‘cookdown’ resulting in just a single ICMP ping per cycle for all circuits.

Neale Brown, Jaime Correia, Pete Zerger any myself have teamed up to write the management pack, documentation and test the solution. A great experience.

Download

The sealed Management Pack and the documentation can be downloaded from the System Center Forum: Download Multi-Host Ping 3.0 Management Pack
Be sure to study the documentation before you implement the Management Pack as there is some required configuration work to be performed.

Scaling-out Operations Manager Web Interfaces

Currently there are several documented ways to install Operations Manager 2007 to fulfill the needs of a high availability environment. Clustering Root Management Server and databases and configuring agent fail-over are options covered in the product documentation.

However; there was no description about how to deploy the product’s web interfaces in a load-balanced web farm. So I wrote a guide which fills the gap by guiding through the configuration of the Web Console and the Reporting Manager web interfaces as a network load balanced web server farm. This is commonly referred to as a scale-out deployment.

When combining the traditional methods of clustering and fail-over with running Operations Manager’s web interfaces in a server farm, a redundancy throughout all components of the product’s infrastructure is achieved.

The document Scale-out deployment of Operations Manager 2007 web interfaces is available for download at the System Center Forum site.

Fully redundant and scaled-out Operations Manager set up

Some people asked if I could update the Scheduled Task Management Pack for Windows Server 2008. So here it is: Scheduled Task Management Pack now does W2K8 .

Windows Server 2008 Task Scheduler 2.0 brings some exciting new features. From the MP author’s point of view the most significant are:

• Full support for scripting: msdn reference
• Very detailed event logging

So for Windows Server 2008 the MP does no longer have to parse the output of a command which makes it much more reliable. And since I was at it, I attempted to make the MPs less power consuming on the agents and the management servers. So I highly recommend upgrading should you still be using an older version.

Thanks everyone who provided valuable feedback during the testing phase.

Introduction

Operations Manager is very flexible about creating dynamic groups based on membership formulas. Such groups can easily be created in the console’s authoring pane and may contain just about any object, SCOM has discovered. For advanced grouping algorithms the management pack XML will have to be written/edited by hand since the GUI wizard does not support contains/contained type rules. If you are not so comfortable with writing management pack XML code, the semi-GUI based method could be used:

1. Prepare the groups using the autoring wizard

2. Export the resulting management pack

3. Edit and add the formulas as required using your favourite XML editor

4. Reimport the management pack

Such groups can serve for overrides, console views, console scopes, alert subscriptions and much more. All in all very powerful and flexible. This logic can be applied not only to the groups visible in the operator GUI. The group populator comes in particularly handy when designing dynamic distributed applications.  Populating distributed application elements works just the same.

Grouping options

The membership of a dynamic group is defined by applying at least one of the following methods. All of them can be freely combined and nested:

• Object’s class membership (MonitoringClass)

  • Example: SingleClass.Group.DiscoveryRule.xml

• Properties of an object (Property)

  • Example: ObjectProperty.Group.DiscoveryRule.xml (using RegEx)

• Properties of an object’s host (HostProperty)

  • Example: HostProperty.Group.DiscoveryRule.xml

• Children of an object (Contains / NotContains)

  • Example:  Contains.Group.DiscoveryRule.xml

• Parents of an object (Contained / NotContained)

  • Example:  Contained.Group.DiscoveryRule.xml

• Each dynamic group may be defined by more than a single membership rule.

  • Example: HealthServiceContainment.Group.DiscoveryRule.xml (includes a nested formula)

Contains/Contained evaluation performance

However; adding many dynamic groups to your SCOM could have a negative impact on the performance of the Root Management server. All groups are (internally) hosted by the RMS and it does all the dynamic group membership calculation. I have seen dramatic performance degradation even on mid-sized SCOM installations. Eventually this led to the GroupPopulator module (Microsoft.SystemCenter.GroupPopulator) being way behind the discovery process.

After some investigation it turned out that the use of the Contains/Contained expressions was causing the problem. Group calculation has to walk down (contains) or up (contained) the hosting and containment relationships for every object of the grouping class in order to decide if it is to become a member of the dynamic group or not. In a deep class hierarchy this query can become quite heavy.

If using that type of dynamic inclusion rules, there are two simple points to watch out for.

• Choose grouping class (MonitoringClass) as specific as possible

Select the grouping class (MonitoringClass)  so that the group calculator does not have to evaluate too many objects. Avoid using System.Entitywhenever feasible. If your group must contain objects of different classes, rather use several membership rules (MembershipRule).

• Set maximal query depth (maxDepth) attribute

All four (not)contained/(not)contains rules do support limiting the search depth of the query. The optional attribute maxDepth is used for that. Whenever possible think about how deep the module must look for and set the maxDepth attribute to that value. Quite often a “1″ might be sufficient – for example to query for direct members of an object. Above examples all have the attribute set.

Real world examples

A very useful and neat example to show what can be done by using dynamic groups, was published by Tim McFadden. In his post he explains how to create a group that contains both server and health watcher objects. Great for using in subscriptions in order to receive alerts about failed health services as well. Tim uses two membership rules (one for the windows computers, the other one for the health service watchers) and does show how contained/contains can build up onto each other. The result could look like this: HealthServiceContainment.Group.DiscoveryRule.xml

Brian Wren writes about how to programmatically create groups that can make use of dynamic grouping formulas.

Brian also has a detailed post on how to create dynamic component groups for distributed apllications.

To create groups based on the AD security group membership of an agent system, follow Steve Rachui’s how-to.

Remark on MPVerify

Unfortunately the current version of MPVerify.exe (SP1) is unable to check if the inner logic of group calculation discovery rules is valid. The same is true for MPSeal.exe.  It is crucial that even after successfully checking or sealing a management pack, you go back to your RMS’ event log to look for any warning or error messages thrown by the GroupPopulator.

• Event ID 4509 (The constructor for the managed module type “Microsoft.EnterpriseManagement.Mom.DatabaseQueryModules.GroupCalculationModule” threw an exception)

Happy grouping!

About a month ago version 6.0.6452.0 of the Active Directory management pack was released by Microsoft. That version does discover trusted domains out of the box. However; it still does not discover forests and domains to which no trust exists. But it can be done:  The trick simply is to run the ‘AD Topology Discovery’ on OpsMgr gateways located in domains and not just on the RMS.

The management pack below consists of :

• AD Discovery Management Server Computer Group: Gateways installed in domains
• Discovery of the AD Discovery Management Server Computer Group
• AD Topology Discovery (Custom script): targeted at all management servers - disabled by default
• Override to enable the discovery on members of above group

In order to successfully discover domain objects, the OpsMgr security gateways need to have the right to ‘act as a proxy and discover managed objects on other computers‘.

Download the management pack

Download Custom AD Topology Discovery MP V 1.0.2.0 (unsealed) (rename after downloading – it is a zip archive)

It should be mentioned that there is some overhead since the discovery is run on all gateways in an untrusted domain. For that reason I set the execution interval of the discovery script to 6 hours.

Note on earlier versions

If you happen to have been using the workaround MP I posted earlier this year: The old version (V 1.0.0.0) does not work with Microsoft’s management pack  6.0.6452.0 and above.  Please replace it with the current MP.

Two weeks ago I had the opportunity of talking about the Active Directory integration feature in Operations Manager 2007 at the 3rd meeting of the System Center Virtual User Group. The presentation included details of how to implement AD integration in complex enterprise environments.

As a follow up to the meeting, Pete Zerger invited me to participate in updating the AD integration guide at the System Center Forum Community site.

The document contains in depth information about:

• what AD Integration is
• how it works
• configuring for single as well as multiple domain sites
• agent roll-out
• troubleshooting
• LDAP query examples

If you plan to roll out AD integration this should give you the answers to most of the questions you might have.

Links

Active Directory Integration Guide (System Center Forum)

Active Directory Integration slide deck (3rd SCVUG Meeting)

AD Integration (untrusted domain)

When using OpsMgr’s Active Directory integration for remote (untrusted) domains, you will receive alerts by two monitors, complaining that the RunAs accounts used for the remote domain integration were not correctly configured. The monitors are defined in Microsoft.SystemCenter.2007 MP:

•   RunAs Account Monitoring Check
•   RunAs Successful Logon Check                                             

This is actually expected since the Root Management Server can not log on in its local domain using the remote user. In order to suppress these alerts you could disable the monitors (in the context of the RMS), using overrides. The downside of this is that you would miss out on any other locally defined RunAs accounts’ failures.

I chose an alternate approach by disabling the original monitors and replacing them with new ones, which allow filtering on the RunAs user account’s name.  The replacement monitors are:

• RunAs Successful Logon Check (Replaced)
• RunAs Account Monitoring Check (Replaced)

In order to reuse these two in your own environment, edit above monitors and replace the account names in the unhealthy event expression (FirstExpression) with the account names you would like to exclude from the RMS monitors. Should one of your RunAs accounts in the untrusted domains become invalid, you will receive other alerts from the AD writer.

Download link for a sample MP containing the RunAs overrides and monitors:
Custom.AD.Integration.Untrusted.RunASMonitorsExtension.xml MP V 1.0.0.0 (rename after downloading – it is a zip file)