SCOM Admin needs to know the basic structure of Management packs and knowledge about classes and objects, what are the differences between the classes, and what is the projection of choosing a class.
Management packs provided by the products companies like Microsoft for Active Directory Exchange, and so forth, do the work for us, by providing the classes and discoveries for monitoring targets, in order to adapt the good method for the custom management packs, we have to write classes of our own.
When we need to create new custom monitors you must select a Target, Target is a class that host objects, the monitoring that we create will apply to all objects in their classes. For example, Windows Computer contains all the Computer objects, you can override on a group or object.
When we decide which target to set up, and you need to enable the monitor on part of objects, it is wrong to think that all the monitors can be manipulated on Windows Computer Class or on any other existing class, the main effect is on system performance the unmonitored monitors on windows computers objects are cause slow down the system in the future.
Example of side effects will arise when we will try to manage and display the services state, we couldn’t select the Windows Computer Object in the dashboards, because not all monitors necessarily belong to this service, and it’s will have effect on this service.
Therefore, there is a need to create classes then identify the servers on which the services are based, and on which we will define the monitoring.
Some of the tools for creating classes are MP Author and Visual Studio.
Kevin Holman has written a library that contains numerous examples of using VSAE to create class: https://gallery.technet.microsoft.com/SCOM-Management-Pack-VSAE-2c506737
But the discovery classes in the library are based on Local Application that represent only one base class type and the main roles on server and not the components of this role.
——————————————————————————————————
Local Application and Application Component Base Classes types and their differences:
Windows LocalApplication / Unix LocalApplication
Application often installed with others on the local computer
- Hosted by Windows Computer or Unix Computer
- Automatic Health Rollup to Computer
Windows ApplicationComponent / Unix ApplicationComponent
Component of a local application or computer role
- Unhosted; Create your own relationship
Local Application classes, represent a defined role installed on the server, and are hosted by default under the Windows / Linux Computer class, therefore computer automatically inherit the State, and if so, when a monitor in Child goes to Critical, the Parent is also colored and changes its state.
When we need to monitor components of this Role, and we want to represent them under it, we need to create sub-classes based on Application component, but since the Unhosted class definition, is required to define a relationship between the parent class and the sub class that we will now going to create.
Example of Parent and child class:
In the MP attached, there is a class based on Local Application that be the main class for this example (I used the Kevin Holman Fragment – Class.And.Discovery.Script.PowerShell.mpx).
Now we will create an Application Component sub-class that will link to the parent Local Application to which we want to associate to.
It is important to understand that the state will not affect the parent unless we want it to [hence the continuation].
Steps:
- Add new Sub-class base on Windows!Microsoft.Windows.ApplicationComponent:
<ClassType ID=”DEMO.ApplicationComponent.Class” Abstract=”false” Accessibility=”Public” Base=”Windows!Microsoft.Windows.ApplicationComponent” Hosted=”true” Singleton=”false”>
<Property ID=”<PropertyA>” Key=”false” Type=”string”/>
<Property ID=”<PropertyB>” Key=”false” Type=”string”/>
2. Create the relationship to the Local Application main class:
<RelationshipType ID=”LocalApplicationHostsApplicationComponent” Base=”System!System.Hosting” Accessibility=”Public”>
<Source ID=”LocalApplication” Type=”DEMO.LocalApplication.Class”/>
<Target ID=”ApplicationComponent” Type=”DEMO.ApplicationComponent.Class”/>
3. Add discovery targeted to Windows Operating System class, to discover the components [Script Discovery, you can use any discovery process according to the application setting]:
<Discovery ID=”DEMO.ApplicationComponent.Class.Discovery” Target=”Windows!Microsoft.Windows.Server.OperatingSystem” Enabled=”true” ConfirmDelivery=”false” Remotable=”true” Priority=”Normal”>
<Category>Discovery</Category>
<DiscoveryTypes>
<DiscoveryClass TypeID=”DEMO.ApplicationComponent.Class“>
<Property PropertyID=”PropertyA”/>
<Property PropertyID=”PropertyB”/>
</DiscoveryClass>
</DiscoveryTypes>
<DataSource ID=”DS” TypeID=”Windows!Microsoft.Windows.TimedPowerShell.DiscoveryProvider”>
<IntervalSeconds>86400</IntervalSeconds>
<SyncTime />
<ScriptName>DEMO.ApplicationComponent.Class.Discovery.ps1</ScriptName>
<ScriptBody>
<Discovery Script body>
</ScriptBody>
<Parameters>
<Parameter>
<Name>SourceID</Name>
<Value>$MPElement$</Value>
</Parameter>
<Parameter>
<Name>ManagedEntityID</Name
< Value> $Target/Id$</Value>
</Parameter>
<Parameter>
< Name> ComputerName</Name>
< Value> $Target/Host/Property[Type=”Windows!Microsoft.Windows.Computer”]/PrincipalName$</Value>
</Parameter>
</Parameters>
<TimeoutSeconds>120</ TimeoutSeconds >
</DataSource>
</Discovery>
3. Import the Management Pack – Local Application class and a Sub-class based on Application Component are created based on the discovery condition
NOTE – When the child object goes to Unhealthy the father by default remains Healthy
To add interdependence, you need to add Dependency Monitor and select Object (Hosting)
Now when the child object goes to Unhealthy the parent changed also to Unhealthy
You must log in to post a comment.