Situation:
You are tasked with creating a new ManagementPack for your organization. You post a sign outside your cube: “HELP WANTED!” You have no idea what one is much less how to put one together.
Solution:
The authoring Guide inside the tools directory will help.
So will the links below:
Tip #1:
All ManagementPacks start this way:
<ManagementPack ContentReadable="true" mlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<Manifest>
<Identity>
<ID>ADMS.Windows.Server</ID>
<Version>1.0.000.0</Version>
</Identity>
<Name>ADMS Windows Server</Name>
<References>
<Reference Alias="System">
<ID>System.Library</ID>
<Version>6.1.7221.0</Version>
<PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
</Reference>
</References>
</Manifest>
</ManagementPack>
Tip #2:
The ID of the ManagementPack needs to be exactly the same name of the saved xml. In-other-words, the ManagementPack filename would be: ADMS.Server.xml.
Tip #3:
The friendly name of the ManagementPack is generally the name of the ManagementPack without the file extension and the dots.
Tip #4:
The version number below the ID is very important as when you make changes to the ManagementPack and import it into the console you need to increase the version number or your changes will not go into effect.
Tip #5:
The naming conventions for the references are fairly standard. Below are the core references you’ll want to use:
ALIAS | ID | Version | Public Key Token |
System | System.Library | 6.1.7221.0 | 31bf3856ad364e35 |
Windows | Microsoft.Windows.Library | 6.1.7221.0 | 31bf3856ad364e35 |
Heath | System.Health.Library | 6.1.7221.0 | 31bf3856ad364e35 |
Performance | System.Performance.Library | 6.1.7221.0 | 31bf3856ad364e35 |
SC | Microsoft.SystemCenter.Library | 6.1.7221.0 | 31bf3856ad364e35 |
SCDW | Microsoft.SystemCenter.DataWarehouse .Library | 6.1.7221.0 | 31bf3856ad364e35 |
SCIG | Microsoft.SystemCenter.InstanceGroup .Library | 6.1.7221.0 | 31bf3856ad364e35 |
Reports | Microsoft.SystemCenter.DataWarehouse .Report.Library | 6.1.7221.0 | 31bf3856ad364e35 |
Tip #6:
Why use the System.Library? Because it is the core system library that every other library references.
Why is it referenced by every other library? Because, classes are the way you create tables in the SCOM database and classes are required for discoveries, rules and monitors to work correctly.
Tip #7:
Why use the Microsoft.Windows.Library? Because it is the core windows library.
Additional usable classes and relationships are standard hardware and software features and, again, are required for discoveries, rules and monitors to work correctly.
Tip #8:
Why use the System.Health.Library? All monitoring and the views that represent the data generated by the monitors use the health library.
Tip #9:
Why use the System.Performance.Library? Any area that represents performance such as performance rule collections and alerts use the Performance library.
Tip #10:
Why use Microsoft.SystemCenter.Library? Essentially, this library binds SCOM to the ManagementPack. From Classes to Views – including folders – this library is used to make the mp and SCOM interactive.
Tip #11:
Why use the Microsoft.SystemCenter.DataWarehouse.Library? Long term storage of performance counter information is added by referencing this library.
Tip #12:
Why use the Microsoft.SystemCenter.DataWarehouse.Reports.Library? If you plan on using linked reports in the ManagementPack, referencing this library enables you to create and use them.
Tip #13:
Why use the Microsoft.SystemCenter.InstanceGroup.Library? If you plan creating groups and adding computers to those groups, referencing this library allows you to discover and bind the computer relationships with the groups.
No comments:
Post a Comment