Click the Download button to read the technical details and download from the source.

This simple management pack augments Essentials 2010 functionality by adding one-click magic packet delivery using a custom task. The pack includes a custom view and custom task each targeting the 'Network Adapter (Client)' class. 

Requirements

• Requires the free Depicus wake-on-LAN command line utility (wolcmd.exe) extracted to c:\tools.
• Also requires that wake-on-LAN functionality is available and enabled in your managed client computers. 

For example, Dell makes a utility you can use to enable wake-on-LAN on your Dell desktop and laptop computers through a msi package created with the Dell Client Configuration Utility (DCCU).

• Instructions available at http://www.delltechcenter.com/page/Enable+Wake+On+Lan+with+DCCU.
• Download DCCU HERE.

Known Issues

Due to the way the IP addresses are stored on the Network Adapter class, this task will only work for client network adapters with a single IPv4 address. This means IPv6 should be disabled on the client network adapters in your environment. This should be doable for DHCP clients in most environments today.

UPDATE: 6.0.0.1 version added to resolve issues with alert closing for alerts older than an hour or older than a day.

Filename	Description
System.Uptime.Monitoring.xml	System Up Time Monitoring (unsealed)
Or
System.Uptime.Monitoring.mp	System Up Time Monitoring (sealed)
OM2007_MP_SystemUpTime.doc	This management pack guide.

Group	Contents
Computers Rebooted Daily	This group can be populated either explicitly or by using dynamic rules to contain systems that have planned scheduled daily reboots. (86400 seconds or 1 day)
Computers Rebooted Weekly	This group can be populated either explicitly or by using dynamic rules to contain systems that have planned scheduled weekly reboots. (604800 seconds or 7 days)
Computers Rebooted Monthly	This group can be populated either explicitly or by using dynamic rules to contain systems that have planned scheduled Monthly reboots. (2592000 seconds or 30 days)
Computers Rebooted Quarterly	This group can be populated either explicitly or by using dynamic rules to contain systems that have planned scheduled Quarterly reboots. (7776000 seconds or 90 days)

Name	Enabled	Type	Description
System Uptime Daily Reboot Monitor	False	Performance	This monitor checks the status of the System Up Time based on the Windows performance counter System: System Up Time. By default, this monitor is disabled. This monitor is configured with a threshold of 1 Day (86400 seconds) and is targeted towards computers in the ‘Computers Rebooted Daily’ group.
System Uptime Weekly Reboot Monitor	False	Performance	This monitor checks the status of the System Up Time based on the Windows performance counter System: System Up Time. By default, this monitor is disabled. This monitor is configured with a threshold of 7 Days (604800 seconds) and is targeted towards computers in the ‘Computers Rebooted Weekly’ group.
System Uptime Monthly Reboot Monitor	False	Performance	This monitor checks the status of the System Up Time based on the Windows performance counter System: System Up Time. By default, this monitor is disabled. This monitor is configured with a threshold of 1 month (30 Days or 2592000 seconds) and is targeted towards computers in the ‘Computers Rebooted Monthly’ group.
System Uptime Quarterly Reboot Monitor	False	Performance	This monitor checks the status of the System Up Time based on the Windows performance counter System: System Up Time. By default, this monitor is disabled. This monitor is configured with a threshold of 1 Quarter (90 days or 7776000 seconds) and is targeted towards computers in the ‘Computers Rebooted Quarterly’ group.

Name	Enabled	Type	Description
System Uptime Collection Rule	True	Performance	This rule collects the 'System Up Time' performance counter. By default it is configured to collect hourly.

Name	Description
System Up Time Report	A general system up time report, chosen by computer group, containing computer name and system up time in descending order by longest up time. Best viewed as an excel spreadsheet.

Name	Description
System Up Time Compliance Report	Chosen by computer group like ‘All Windows Computers’, this report shows computers that have a system up time greater than desired. Best viewed as an excel spreadsheet.

Name	Type	Description
System Up Time Alerts	Alert	All alerts generated from the System Up Time Monitoring Management Pack

Name	Type	Description
System Up Time Performance	Performance	All System Up Time performance counters on all Windows Computers
Just a standard performance view.

Please first read the documentation otherwise the MP will fail…..as you already know as SCOM Experts ;-)

If you have Feedback or addons to the MP please feel free to send them in!

Index:

• Important notice
• Preface
•  Functionality

Using this Management Pack

• Creating Rules in the Management Pack
• Functionality Check
• Questions and Answers

Technical Details

 Important notice

I will not take responsibility for any damage the provided software might cause.

Preface

The idea for developing a Flooding Prevention for Event Rules was born because in our company we collect a lot of events for our in-house applications. Sometimes, there were thousands of events written to the NT Event Log and collected by the SCOM within a few seconds which caused the RMS to crash.

To prevent this, I at first used a Repeated Eventlog Monitor that turns unhealthy in case there are too many events written and potentially collected.

Additionally, I added a Recovery task that would create an override to disable the corresponding rule. In case it’s healthy again it would run a recovery task to delete that override again.

But, we couldn’t use this in a production environment due to the fact that the recovery task would need access to the SDK. Of course, that’s possible but it’s not the way we wanted it to be.

Conclusion: That version was impracticable. So, a new version was developed that does all SDK tasks on the Root Management Server.

Basically it watches the states of the Repeated Eventlog Monitors that run on the machines. In case they turn unhealthy, an Override would be created to disable the corresponding rule. In case they turn healthy again by a manual reset, the override will be deleted.

Things are a bit different in our environment so I had to work out a new version, the one you will see here, which is a lot more self-aware and user-friendly.

Functionality

There are 2 Management Packs, the EventRules.With.FloodingPrevention.Library which contains the required classes, discoveries and rules, and the EventRules.With.FloodingPrevention.Rules Management Pack in which the rules will be created that we are going to monitor.

There is 1 Discovery running on the RMS that reads all Event Rules from the Rules Management Pack and discovers them as an instance of the EventRuleWithFloodingPrevention Class.

Additionally, a Repeated Event Log Monitor will be created for each rule, using the same Event criteria as the rule.

There is 1 Rule running on the RMS which checks the states of the Monitors.

In case one is in an unhealthy state, an Override will be created that disables the corresponding rule.

If the monitor turns healthy again, the Override will be deleted.

Using this Management Pack

Management Pack Configuration

Basically there are 3 parameters you may want to override.

Repeat Count Threshold: How often a rule must collect an event within 60 seconds until it gets disabled.

Default: 5 (for Presentation purpose)

Monitor Creation Frequency: How often the Management Pack is checked for new rules.

Default: 300

Recommended: >60 

Flooding Prevention Frequency: How often the monitor states will be checked and overrides will be created.

Default: 60

Recommended: >30 

Creating Overrides is kind of user-unfriendly in the Authoring Console, therefore import both Management Packs (Sealed Library MP and unsealed Rules MP) in your Environment, preferably your LAB Environment.

 Adjusting Repeat Count Threshold and Monitor Creation Frequency:

In the Operations Console, open the Authoring Pane\Management Pack Objects\Object Discoveries and search for: Rule Discovery

 Right-Click it\Overrides\Override the Object Discovery\For all objects of class: Root Management Server

Adjust the Interval and the MonitorRepeatCountThreshold.

Select destination management pack: Event Rules with Flooding Prevention Rules

 Hit Apply – OK.

Adjust the Flooding Prevention Frequency:

In the Operations Console, open the Authoring Pane\Management Pack Objects\Rules and search for: Handle Overrides

Right-Click it\Overrides\Override the Rule\For all objects of class: Root Management Server

 Adjust the Interval Seconds.

Select destination management pack: Event Rules with Flooding Prevention Rules

 Hit Apply – OK.

 Creating Rules in the Management Pack

Basically, all you have to do is creating an Event Collection rule and as the target select Windows Computer or anything that is hosted by it. However – here’s a short walkthrough.

 Import the Management Pack and in the Operations Console, go to the Authoring Pane.

Go to Management Pack Objects – right-click Rules and select “Create a new rule…”

 Open Collection Rules\Event Based and select NT Event Log. (Also works with Alert Generating Rules but there’s no real purpose for that because of the Alert Suppression functionality.)

Select destination Management Pack: Event Rules with Flooding Prevention Rules.

Click Next.

Give the rule a name (Has been tested with special characters, works fine). Set the Category and select a Rule Target.

IMPORTANT: The rule’s target has to be something that is hosted by Windows Computer.

Next – The rest doesn’t need any further explanation. Configure the Event Log Type and build the Event Expression and click Create.

Functionality Check

Once the Discovery runs again, it’ll create new Instances of the Flooding Prevention Class.

To verify this, in the Operations Console open the Monitoring Pane, open the folder “Event Rules with Flooding Prevention” and open the States view.

You should now see a discovered instance for all “Windows Operating System” Computers.

Next, we create a few Events to get the Monitor to turn into a Warning state.

Launch the Command prompt from a machine where the Monitor runs and create new events that match the criteria you configured for your rule. Since I use a RepeatCountThreshold of 5, I create the Event 5 times.

In my case the command looks like this:

eventcreate /T Information /ID 514 /L Application /D "Test"

After a few seconds the state should turn into Warning state and we receive an Alert which you can find in the Alerts view.

Since the creation of the Override is done by a separate rule, it may take a while (depending on the Interval you chose for the HandleOverrides rule) until the Override is created.

Go to the Authoring pane\Management Pack Objects\Overrides and search for the rule name (in my case Dust 514).

You should find 2 overrides, one for the monitor and one for the rule (we are interested in the rule override).

And, as you can see, the Override was created specifically for the machine that caused the error.

Let’s check if it resolves properly by going to the State View again and resetting the state of the Monitor.

The next time the HandleOverrides rule runs, the Override will be deleted again.

Verify this by going to the Authoring pane, searching for the rule. The override should be gone.

Questions and Answers

What if the rule criteria changes?

The script will check if the criteria changed for existing monitors, therefore if you changed the rule criteria, the monitor will be updated as well.

The scripts do all kinds of automatic creation so what if a rule is gone?

A recycling job will run during the discovery that gets rid of unused groups, monitors and overrides.

Doesn’t this cause a lot of load on the RMS?

I couldn’t see much change in the performance on the RMS, besides: The SDK is very fast.

I have tested this with a few rules in our production environment targeting 250+ computers and the scripts took about 10 seconds.

What takes some time is the SDK connection setup.

Technical Details

Terminology:

PartialMonitoringObject:       Is a discovered class instance like a Windows Computer or a Logical Disk that has a health state which is changed by the monitor that targets it.

 Discovery - FloodingPreventionV3.Script.CreateMonitors.PS1

Checking Rules:

First, the script iterates through all rules and checks if data source is either Microsoft.Windows.EventCollector or Microsoft.Windows.EventProvider by using a string.contains(“Microsoft.Windows.Event”)

For each rule that passes this check, 3 sub-functions will be called:

#1 Discover-ClassInstances

In this function, we assume that the rule’s target is or is hosted by Windows Computer.

We then get all PartialMonitoringObjects of the class and create a new Classinstance of type EventRules.With.FloodingPrevention.Class.EventRuleWithFloodingPrevention

Class Properties:

DisplayName: The Display Name of the rule.

PrincipalName: The  current PartialMonitoringObject’s hosting Computer Name.

MonitoringRuleID: The GUID of the rule. [This is the key property for the class]

MonitoringRuleName: The XML ID of the rule.

 Note:Only one instance per computer will and can be discovered. If there are no instances found for the rule’s target class, the rule will be skipped.

#2 Create-FloodingPreventionMonitor

Will check if the monitor has been created already, in case it hasn’t, a new one will be created using the event criteria from the rule.

In case a monitor for this rule exists already, it’ll check if there were changes in the event criteria. In case there was a change, the monitor’s event criteria will be updated.

Information on the Monitor:

Target: Is the FloodingPrevention class (explained in #1)

Enabled: false, we’ll enable it in #3

Configuration: As mentioned already, it uses the event criteria from the rule. However, the schema is a bit different on the monitor so we run it through a translation sub-function so we get a proper configuration for the monitor.

                                    For the repeat count threshold we use the one provided in $monitorRepeatCountThreshold which can be configured in the Discovery.

#3 Create-Group

Creates a new group for each rule containing the class instances with the MonitoringRuleID of the current rule’s GUID.

Target: The FloodingPrevention class.

Membership: The MonitoringRuleID property has to match the rule’s GUID.

Additionally, a new Override will be created that enables the current rule’s monitor for this group.

Recycling Rules:

The recycling process runs every time the discovery runs and there were no changes to the Management Pack so far.

Basically, it checks the rule’s group for the member count, and in case the member count is 0, all associated objects in the Management Pack will get removed by 3 sub-functions.

#1 Delete-Override

Deletes the Override for the monitor and in case there are still overrides for the rule, they’ll get removed as well (they’ll get removed automatically in usual case).

#2 Delete-Group

Deletes the group as well as it’s discovery.

#3 Delete-FloodingPreventionMonitor

Deletes the Monitor. 

Flooding Prevention – FloodingPrevention.Script.HandleOverrides.ps1

Check Health States:

It’ll get all PartialMonitoringObjects of the Flooding Prevention Class and checks their state.

# Warning State

Calls the Create-Override function which checks if there is already an override created for this instance. If not, an override will be created that disables the corresponding rule for the server which collected too many events.

# Healthy State

Calls the Delete-Override function which checks if there is an override created for this instance. If yes, the override will be deleted.

Currently Microsoft SQL Server 2008 (any edition) is supported. Support for SQL Server 2005 is planned for a future release if demand justifies the effort.

Use the SQL Server DB Mirroring Management Pack for:

• Monitoring the availability state of mirrored databases and witnesses.
• Monitoring if the mirrors are operating in line with a Desired Configuration definition.
• View mirrored DBs as a service components and use them for Distributed Application designs.
• Report on SQL database mirroring configuration.
• Use the objects and groups discovered to add SQL database mirroring specific rules, monitors or overrides.

The Management Pack download contains a comprehensive guide that carefully lists all prerequisites. As a supplement it also contains an override MP that works in conjunction with the Extended Microsoft SQL Server MP hosted on OpsManJam. It shows how to use the discovered objects of the SQL Server DB Mirroring MP to parameterise existing or now MPs to support DB mirrors.

Download the SQL Server DB Mirroring Management Pack by clicking on the Download button in the upper right corner (bust be logged in - registration is free).

For a full list and description of the tasks included, see the MP report and MP guide included in the zip file download.

This management pack contains more than 40 audit rules (+ views and a report)  designed to alert administrators to various changes in Windows 2008 Active Directory related to users, groups, group policies (GPOs), OUs and physical topology (sites, site links and subnets). Care has been taken to avoid the use of wildcards on description fields for better performance.

In fact, I made several design decisions to help scale and database space utilization.

• It contains a seed base class (called Windows 2008 Active Directory Audit Target) so you can limit agents that load these workflows
• Uses alert rules instead of event collection rules resulting in less space consumed in the operational and data warehouse data
• Contains separate alert views for User, Group, OU, GPO, and Physical Topology events
• Uses rules instead of monitors - audit events should NOT affect health of AD in my opinion! These are more for catching unauthorized changes.
• Only DELETE operations generate critical alerts...all other generate warning alert
• Currently contains a linked report for audit alerts. Will likely add custom reports to later versions.

NOTE: This is the official release, which includes a detailed management pack guide.

The download has been updated with the latest version of the MP.  A number of people had reported issues with both reports which should now be resolved.

I have also had to change the certificate used to seal the management pack so if you were using the sealed version of the MP, you will need to export it before importing the new version.  If you were using the unsealed version, you should be able to upgrade.

David

-----

This management pack is an extension management pack the collects detailed logical disk data, has a task that analyzes logical disks and contains views and reports to consume all the information collected.

Click the download button to download the ZIP file contains a sealed and unsealed copy of this MP.  The ZIP file also contains documentation for the management pack which details what is in the MP and how it works.  So full for details, download now :-)

Feel free to post any thoughts/comments/issues you have regarding this MP !

David

For more information on the contents of this pack, see

SQL Admin Extensions Sample MP for OpsMgr 2007 and Essentials 2010