I used Device Status Check monitor in my last post when providing realistic sample of how to define alert settings thru overrides. Unfortunately, and mainly because of override value restriction regarding use of parameter replacement, description of such alert was not able to benefit from property values of its target instance (could not use device name, IP Address and others with alert description). This led me to work on this post, although it is rather possible some other guys already did similar work …

So to help Tim, I decided to customize that monitor without forcing customization thru overrides. I had used regular text editor to create everything in raw XML, but here is how I would approach this problem if had no access to “internal” unsealed version of shipped MP and would need to use our authoring tools.

 

·         Create new empty management pack in our authoring console. I only need to do this if I do not have MP with customization and/or overrides for that particular managed entity type already.

·         Next I need to find management pack holding the definition of monitor I want to customize. Then I need to export this management pack. (UI won’t allow exporting sealed MP, but we have Powershell!)

$monitor = Get-Monitor -Criteria "DisplayName = 'Device Status Check'"

$monitor.GetManagementPack() | export-managementpack –path c:\

·         Open this MP in regular text editor (it is stored in path used with commandlet) and copy unit monitor I want to customize into my custom MP file. This all work raises and falls on accessibility of managed entity used as target as well as accessibility of monitor type used with unit monitor implementation. Target of your monitor MUST be public (to be accessible outside of MP where it is defined) and same goes for monitor type you are implementing (monitor type is driven by TypeID attribute). Please be aware of referencing. When copying monitor into your custom MP, you need to provide reference to MP where those elements are defined. Please observe how it is done in attached file. Also, ID for this monitor needs to be changed; it is sufficient to simply add string Custom to the end of original ID. Also, this monitor needs to go to Monitoring -> Monitors section, please create those tags when not present.

NOTE: When you do not make this effort, your MP will not pass verification and authoring console will not load your MP for further customization!

It is also very good idea to copy KnowledgeBase article for your new custom monitor (if KB exists for original monitor) into your custom MP. Just remember to adjust ID of this article to match ID you had chosen for your monitor. (Attached MP file should be sufficient sample to follow for this paragraph.)

·         Now save this file and re-open in authoring console. Go to section Monitors and provide all display strings to help SDK displaying user friendly strings rather than “ugly” MP element ID strings.

·         Make changes to alert settings of your custom monitor. Remember that you can benefit from all replacements here.

·         Disable original monitor. This is possible to do in UI thru operations console or you can manually add override thru editing raw XML (again we do not have overrides in shipped authoring console yet). Later is in my opinion much better option allowing deployment of compact solution to your customer with disabling original monitor and providing customized approach in one MP import.

 

Original monitor is disabled

 

·         “MPVerify” your file (you can do this thru Tools section of authoring console), save the file, import into product and test its functionality. Once satisfied with results, MP seal and ship to your customers …

 

Next is a screenshot that displays alert after customized monitor picked a problem with SNMP. My customized MP is attached to benefit some of you (I hope); just please remember that its use is bound to usual AS-IS clause…

Alert raised for custom monitor