A template is used in much the same way as a Word template. The user provides some configuration and runs the template. The output is a new management pack or part of a management pack. A template can be used to created classes, rules, monitors, tasks etc. It can be as simple or as complex as required. The goal of templates is to fulfill common monitoring scenarios e.g. monitor a Windows service, monitor a TCP port, and monitor an OLEDB connection. The user does not need to create the individual management pack objects required to achieve the monitoring. Instead they provide the configuration through a simple wizard and OpsMgr runs the template to output the MP fragment.
Templates are used in three places in the OpsMgr console:
When you create a template you can control where it shows up in the UI by using MP folders. I will be adding some tutorials about creating templates on this site.
The attributes of a template are:
|
Name
|
Type
|
Use
|
Description
|
|
ID
|
ManagementPack
UniqueIdentifier
|
Required
|
The identity of the element. This must be unique within all elements of the management pack.
|
|
Comment
|
ManagementPack
String
|
Optional
|
Use for author comments.
|
|
Purpose
|
ManagementPack
String
|
Optional
|
This specifies the type of template. This should be left empty for the template to show up in the Management Pack templates wizard. The two allowed values are RuleCreation and TaskCreation. This will mean the template will show up in the rule or task wizard.
|
The template element consists of three sections.
Configuration
The configuration section defines the XML schema for the template configuration. When the template is executed, the configuration supplied must validate against this schema. This section is defined in the same way as a module configuration schema:
Illustration from Altova XML Spy
Using the optional IncludeSchemaTypes section of the configuration, it is possible to include previously defined schema types to avoid having to define complex schemas more than once.
References
The template will output a management pack fragment. The elements in this fragment will usually need to refer to other management packs. The references section of the template declares the references that should be created in the MP fragment. This will be added to the target management pack if they are not already present. The references are pointers to references in the management pack that holds the template definition. In the example below, the three aliases System, Windows and SC must be defined in the management pack that the template resides in.
<References>
<ReferenceID="System"/>
<ReferenceID="Windows"/>
<ReferenceID="SC"/>
</References>
There is one special reference alias that can be used. This is called Self and would be defined as follows:
<References>
<ReferenceID="Self"/>
</References>
This reference is used if you want the target management pack to reference the management pack that the template resides in. To do this the management pack the template resides in must be a sealed MP.
Implementation
The implementation section is the management pack fragment that will be inserted into the target management pack. No verification is performed on this section as it will not be a valid management pack by itself. In this section there will be references to template configuration and template references. These will be substituted in appropriately when the template is run. The syntax used for these references is:
Here is an example implementation section that defines a task and language pack
<Implementation>
<Monitoring>
<Tasks>
<TaskID="$TemplateConfig/ID$"Target="$TemplateConfig/Target$"Accessibility="Public">
<Category>$TemplateConfig/Category$</Category>
<WriteActionID="PA"TypeID="$Reference/System$System.CommandExecuter">
<ApplicationName>$TemplateConfig/ApplicationName$</ApplicationName>
<WorkingDirectory>$TemplateConfig/WorkingDirectory$</WorkingDirectory>
<CommandLine>$TemplateConfig/CommandLine$</CommandLine>
<TimeoutSeconds>$TemplateConfig/TimeoutSeconds$</TimeoutSeconds>
<RequireOutput>$TemplateConfig/RequireOutput$</RequireOutput>
<Files>$TemplateConfig/Files$</Files>
</WriteAction>
</Task>
</Tasks>
</Monitoring>
<LanguagePacks>
<LanguagePackID="$TemplateConfig/LocaleId$"IsDefault="true">
<DisplayStrings>
<DisplayStringElementID="$TemplateConfig/ID$">
<Name>$TemplateConfig/Name$</Name>
<Description>$TemplateConfig/Description$</Description>
</DisplayString>
</DisplayStrings>
</LanguagePack>
</LanguagePacks>
</Implementation>
When a template is executed the output will be merged into the target management pack. This management pack will then be verified to ensure it is valid before being committed.