blog post

M-Pack Creator v1.5 Release Notes

Introduction: Enter v1.5

We hope that so far the ProtectOrg M-Pack Creator has provided a way in making the management pack creation process a lot more smoother during its first release. But with many first releases the demands and the requirements always change. Not to mention you will always spot areas which can be improved, certain features which would make things so much easier and so forth.

After reviewing the management pack development tasks that we get you start to develop more ideas and more handy techniques which can not only benefit us but also benefit everyone who is currently using the M-Pack creator currently to.

This update is a small update in comparison to the v2.0 version, but these we feel are important updates in order to progress further.

So with that being said, lets get to the unveiling of its new features 🙂

New Features

Additional Monitor Template: Three State PowerShell Monitor

For us this was a very important one to have. When we think of any form of custom monitoring our main choice of leverage mostly tends to be around creating a PowerShell monitor which utilizes the custom modules.

Very typical monitors tend to be if its down label as critical when its up label it as healthy. But what if we want to have an inbetween severity as well? We may have a threshold which would be considered as Warning as well as Critical levels. Which is why we decided to introduce this new monitor into the new M-Pack creator application.

Figure 1.1 shows it listed in the Monitor Design portion of the application. In addition to this in Figure 1.2 you can see there is a template for the PowerShell Script which contains the logic for the three states. All you have to do is place in the logic for your requirements.

Figure 1.1 - Monitor Design Form with Three State Monitor Selected
Figure 1.2 - PowerShell Script template with three state conditions

Adding Alert Parameters to your PowerShell Monitors

We have now made it possible to where you can now add custom alert parameters to your PowerShell Monitors. The additional customizations is very important especially when it comes to the custom modules, we want to be able to have the ability to capture information when we need it and then have it showing in our alert details.

These provide the enrichments which we need to cater to those requirements and beyond. Below in Figure 1.3 shows how this looks when you are presented a window where you can create the parameters. Sort of has a similar feel to how it’s done in System Centre Orchestrator where you can define variables and then add them as additional published data to pass around through the runbooks.

Figure 1.3 - PowerShell Script and Alert Parameters Design

Once you have created your parameters you can now use these to customize your alert description. Figure 1.4 shows how you can now right click into the alert description box and select the parameters which you had declared and these will then be added into your management pack.

Figure 1.4 - Alert Parameters option for alert description

Create Objects only based on Windows Computer Class

We have now enabled the ability to only target the Windows Computer class now. This we imagine would be a big feature as this now will allow you to create management packs just based on monitors, rules as opposed to being able to create a management pack solely based on a custom class.

You have the ability to make custom classes based off the Windows Computer class as well so the user now has the option to create a management pack with a custom class or not. You now have the ability to create monitors only management pack just like how you would do natively within the SCOM console.

Figure 1.5 - Windows Computer Class Selected

Run As Account Dependency Removed

You can now have the ability to not have to use or require a run as account. This feature is perhaps more to support the ability where you can specify base classes as the targets for when you create discoveries, monitors and objects. Where as custom classes you maybe better suited to have a run as account when wanting to control the access to what can be used to run processes.

So here you will be presented with a tick box called No Run As which will disable the box above to note that you are wishing to create an object without a run as account attached.

Before you would get a message stating that you couldn’t proceed to a certain management pack object window because you had no run as account, this has also been removed.

Figure 1.6 - No Run As Option

Application selection for Agent Tasks

To make things easier when it comes to creating agent tasks, diagnostic or recovery tasks, we have now added a feature in where you can now select which application you want to base the task from.

For example some of the typical applications we tend to base our tasks on are things like;

  • PowerShell
  • Command Line
  • Ping

These are some of the typical ones we have now added so you no longer have to specify the whole paths for them. Even taken it a step further and added a selection for both PowerShell 32-Bit and PowerShell 64-Bit depending on your preference.

Figure 1.7 - Tasks Design Form with Application name selections

Bugs confirmed and fixed

The following bugs from the previous version were detected and fixed.

Please see the list below of what is now fixed in this new version;

Bug Name Bug Description Bug Fixed
Knowledge Articles Not Assiged to Monitors When monitors are created knowledge articles are not created Monitors now have knowledge articles assigned
Run As Account freezing management pack Run as account defaulting to Internal option Run as account now can uses Public as default to fix management pack freezing SCOM
PowerShell Monitors not incrementing MP designer statistics Each time a new PowerShell Monitor is created the number for monitors in MP Designer window does not go up Number now goes up each time a new one is created
PowerShell Script extension missing from Probe Actions Each time you create a PowerShell Script for your PowerShell Monitor the extension .ps1 is missing PS1 file extension is now included
Add Monitor button not unlocked for some monitors When the form is filled the Add Monitor button doesn't get enabled for a couple of Monitors Once form is filled the Add Monitor button is unlocked for ALL monitors
PowerShell Script rule has Alert Name and Message PowerShell Script rule asks for Alert Name and Alert Description is not needed as its not an alert monitor or rule PowerShell Script rule asks for Alert Name and Alert Description is not needed as its not an alert monitor or rule
Share this post on Linkedin
linkedin share post icon
Insights
Related posts
orange gradient shield with protectorg logo

Simplify your world...

Speak to an expert to find out which plan is best for you. Security & compliance management solutions.
Get in touch
Expert advice
Easy implementation
Compliance verification