First part: https://maxcoreblog.com/2020/07/23/implementing-scom-managed-modules-part-1/
In the first part, a simplest probe action managed module was created to investigate SCOM managed modules live cycle. For that purpose, the module was fit with excessive logging for very each step. Initial testing scenario was: deploy the MP with the test probe action module, let it run two times, then shut down SCOM Agent. And here the results:
[60900b93-f1de-4b2d-b9f6-ea88e064eae1]:[17:19:27]: SimpleProbeAction class instance is created. Host process PID: 2020; Managed thread: 5
[60900b93-f1de-4b2d-b9f6-ea88e064eae1]:[17:19:29]: Entering Start; Managed thread: 8.
[60900b93-f1de-4b2d-b9f6-ea88e064eae1]:[17:19:29]: First data item requested.
[60900b93-f1de-4b2d-b9f6-ea88e064eae1]:[17:19:34]: Entering OnNewDataItems; Managed thread: 15
[60900b93-f1de-4b2d-b9f6-ea88e064eae1]:[17:19:34]: Received 1 inbound data items of System.TriggerData type.
[60900b93-f1de-4b2d-b9f6-ea88e064eae1]:[17:19:34]: No shutdown in progress.
[60900b93-f1de-4b2d-b9f6-ea88e064eae1]:[17:19:34]: Competed output data item.
[60900b93-f1de-4b2d-b9f6-ea88e064eae1]:[17:19:34]: Next data item requested.
[60900b93-f1de-4b2d-b9f6-ea88e064eae1]:[17:20:34]: Entering OnNewDataItems; Managed thread: 10
[60900b93-f1de-4b2d-b9f6-ea88e064eae1]:[17:20:34]: Received 1 inbound data items of System.TriggerData type.
[60900b93-f1de-4b2d-b9f6-ea88e064eae1]:[17:20:34]: No shutdown in progress.
[60900b93-f1de-4b2d-b9f6-ea88e064eae1]:[17:20:34]: Competed output data item.
[60900b93-f1de-4b2d-b9f6-ea88e064eae1]:[17:20:34]: Next data item requested.
For the first glance, everything looks as expected. A class instance was created. Then in 2 seconds time the instance received Start signal and requested its first data item. 5 seconds late, the first data item was delivered. The inbound data item was “processed” and the next inbound data item requested. Then exactly 60 seconds later (which is the hard-coded interval for the scheduler data source module) another data item was delivered, processed, etc.
However, there are two oddities. Firstly, there was a rule and a monitor, each of them suppose to run every minute. So, why are there just one instance ID?
Does this mean, that just one class instance created to server both the rule and the monitor?
Cookdown. What is it?
Yes, that’s right. This is called cookdown. Despite many MP developers find this complicated, the cookdown principle is extremely simple: if multiple rules and/or monitors use the same data source type with exactly the same configuration, only one instance of such data source will be created. In this example, both the rule and the monitor use the “Maximus.Research.ManagedModules.SimpleProbeAction.DataSource” data source, both with empty (and therefore identical) configuration. This is why, SCOM Agent created one and only one instance of the SimpleProbeAction C# class. When the instance emits an output property bag data item, it’s sent to both rule’s write action and to monitor’s condition detections for analysis.
Cookdown has great advantage. It makes possible to read multiple parameters in a single procedure, and then analyse them in different monitors/rules. Say, there is a procedure, which reads absolute disk free space (in bytes), total disk size, and relative disk free space (in percents). Then there are two monitors to analyse and alert separately on percent free space left and on MegaBytes left, then three performance collection rules to log free space bytes, percent, and total size, as well as an another rule to run an automation procedure to extend the disk if it gets lower than a certain value. All these workflows will be fed by copies of a single property bag data item from a single poll. Which means, that SCOM Agent will not be constantly polling disk API to query same information again and again.
But cookdown is very fragile. Say, this hypothetical disk probe data source has configurable polling interval. All the rules and monitors from the example above use the same interval of, say for instance, 300 seconds. But also all the rules and monitors allow to configure polling interval. With the default configuration, it was running all fine, and a single class instance was doing single polling every 5 minutes. But then an operator decided to change polling interval for the disk extension rule, then polling will performed once at +5 minutes, at +10, … , and two time at +60, then one time at +65 minutes, and so on. If yet another rule overrides, say performance to write free percent is set to 6 minutes, then polling will be performed at +5, +6, +10, +12, …, then three times on +60, and so on.
Agent Shutdown. Anything Special?
What is about the second oddity. The scenario included SCOM Agent service stop, thus it’s expected the agent to send shutdown signal to all managed modules, so they can release used resources. However, this doesn’t happen. The log doesn’t have an “Entering Shutdown()” record. Microsoft doesn’t specify why agent shutdown is done this way, but I suspect that this is to avoid huge delays, if any modules cannot stop quickly. In the reference Microsoft module design, which is implemented in this example, the actual monitoring job is done under lock() statement, thus if SCOM Agent sends shutdown signal while long-running monitoring job is active, it will wait until the job is done.
On-demand call from Agent Task.
On the top of the rule and the monitor, out test management pack also has an agent task, which uses the same probe action managed module. If the task is executed from SCOM Console application, will it re-use the same class instance? The answer is “No”. It will not re-use the same class instance, because cookdown is only applicable to data sources. But the task calls probe action directly. Let start the task and investigate the log.
[4c236407-9246-45cf-8c5f-56e874036505]:[17:24:28]: Entering OnNewDataItems; Managed thread: 21
[4c236407-9246-45cf-8c5f-56e874036505]:[17:24:28]: Received 1 inbound data items of System.TriggerData type.
[4c236407-9246-45cf-8c5f-56e874036505]:[17:24:28]: No shutdown in progress.
[4c236407-9246-45cf-8c5f-56e874036505]:[17:24:28]: Competed output data item.
[4c236407-9246-45cf-8c5f-56e874036505]:[17:24:28]: Next data item requested.
[2b2c58f7-577d-4a87-b1fc-289955273cb3]:[17:25:14]: SimpleProbeAction class instance is created. Host process PID: 27516; Managed thread: 5
[2b2c58f7-577d-4a87-b1fc-289955273cb3]:[17:25:14]: Entering Start; Managed thread: 5.
[2b2c58f7-577d-4a87-b1fc-289955273cb3]:[17:25:14]: First data item requested.
[2b2c58f7-577d-4a87-b1fc-289955273cb3]:[17:25:14]: Entering OnNewDataItems; Managed thread: 5
[2b2c58f7-577d-4a87-b1fc-289955273cb3]:[17:25:14]: Received 1 inbound data items of BaseData type.
[2b2c58f7-577d-4a87-b1fc-289955273cb3]:[17:25:14]: No shutdown in progress.
[2b2c58f7-577d-4a87-b1fc-289955273cb3]:[17:25:14]: Competed output data item.
[2b2c58f7-577d-4a87-b1fc-289955273cb3]:[17:25:14]: Entering Shutdown; Managed thread: 6.
[2b2c58f7-577d-4a87-b1fc-289955273cb3]:[17:25:14]: shutdown is set to True.
[4c236407-9246-45cf-8c5f-56e874036505]:[17:25:28]: Entering OnNewDataItems; Managed thread: 60
[4c236407-9246-45cf-8c5f-56e874036505]:[17:25:28]: Received 1 inbound data items of System.TriggerData type.
[4c236407-9246-45cf-8c5f-56e874036505]:[17:25:28]: No shutdown in progress.
[4c236407-9246-45cf-8c5f-56e874036505]:[17:25:28]: Competed output data item.
[4c236407-9246-45cf-8c5f-56e874036505]:[17:25:28]: Next data item requested.
In this log, GUID ending 6505 is instance ID for the regular data source instance, and the one ending 3cb3 is for the instance used by the task. Two differences are here, comparing to the regular action. The most distinctive one, is, of cause, is direct call of the “Shutdown()” method. SCOM Agent don’t need to worry about operation time for a one-off user-initiated action for a single module, so the proper module shutdown procedure is performed. The second difference is in inbound data item type: it’s System.TriggerData for the regular action (i.e. sent by the Scheduler module) and it’s BaseData, when run as part of interactive task. Usually, this doesn’t make big much difference, because triggering data items are just to start probe, so their content is dropped. However, this difference allow to implement the probe differently depending if it’s a part of regular or one-off schedule. For example, for regular probe, when actualized data is needed, the probe will not use any cached results, but the manual task probe may not perform actual reading, but get data from cache. There is yet another triggering data item type, but it will be investigate later.
Management Pack Upgrade.
Next experiment is to investigate MP upgrade in general, and class library upgrade. Say, some changes have been made to the class, which implements this probe action. How SCOM Agent will load the new class library and replace instances of the old class with the new ones? To emulate this situation, class library version need to be incremented, and respective changes done to the resource section in the MP as shown below:
[assembly: AssemblyVersion("1.0.0.3")]
[assembly: AssemblyFileVersion("1.0.0.3")]
<DeployableAssembly ID="Maximus.Research.ManagedModules.Modules.DeployableAssembly"
HasNullStream="false" Accessibility="Internal"
FileName="Maximus.Research.Modules.dll"
QualifiedName="Maximus.Research.Modules, Version=1.0.0.3, Culture=neutral, PublicKeyToken=fd5098a6a3259696" />
Now, let’s deploy the new version and watch the log:
[4c236407-9246-45cf-8c5f-56e874036505]:[17:57:28]: Entering OnNewDataItems; Managed thread: 66
[4c236407-9246-45cf-8c5f-56e874036505]:[17:57:28]: Received 1 inbound data items of System.TriggerData type.
[4c236407-9246-45cf-8c5f-56e874036505]:[17:57:28]: No shutdown in progress.
[4c236407-9246-45cf-8c5f-56e874036505]:[17:57:28]: Competed output data item.
[4c236407-9246-45cf-8c5f-56e874036505]:[17:57:28]: Next data item requested.
[1d609cc8-1d54-4a2e-b6bc-a80894f4ed5c]:[17:57:45]: SimpleProbeAction class instance is created. Host process PID: 27832; Managed thread: 57
[4c236407-9246-45cf-8c5f-56e874036505]:[17:57:46]: Entering Shutdown; Managed thread: 57.
[4c236407-9246-45cf-8c5f-56e874036505]:[17:57:46]: shutdown is set to True.
[1d609cc8-1d54-4a2e-b6bc-a80894f4ed5c]:[17:57:46]: Entering Start; Managed thread: 63.
[1d609cc8-1d54-4a2e-b6bc-a80894f4ed5c]:[17:57:46]: First data item requested.
[1d609cc8-1d54-4a2e-b6bc-a80894f4ed5c]:[17:58:28]: Entering OnNewDataItems; Managed thread: 63
[1d609cc8-1d54-4a2e-b6bc-a80894f4ed5c]:[17:58:28]: Received 1 inbound data items of System.TriggerData type.
[1d609cc8-1d54-4a2e-b6bc-a80894f4ed5c]:[17:58:28]: No shutdown in progress.
[1d609cc8-1d54-4a2e-b6bc-a80894f4ed5c]:[17:58:28]: Competed output data item.
[1d609cc8-1d54-4a2e-b6bc-a80894f4ed5c]:[17:58:28]: Next data item requested.
There are few interesting features about the sequence of the events above. First, an instance, based on the new class version was created before the old one received shutdown signal. However, the new instance received start signal only after the old instance got its shutdown signal. This is very important if an implemented monitoring workflow needs exclusive access to any resources. For example if a file open for write without sharing, or a DB or API allowing a single connection per user, etc. From practical perspective, that means, that allocation of resources (files, connections, etc.) should be performed in the Start() method, and release of allocated resources should be performed in Shutdown() method. This is especially important for exclusive resources to avoid denial exceptions.
The second interesting feature, is that probe action pace didn’t change. I.e. the previous in instance was receiving triggering data item at XX:28, so the new one receives triggers at the same second offset. This is because not the whole composite data source module was re-created, but just the probe action module.
Cookdown and Configuration.
Let’s get back to cookdown and investigate managed module lifecycle when data source configuration is different. And also make an experiment to align the configuration — will it make SCOM to destroy extra module instances?
First, prepare a new class and make all necessary wrappings. I made a full copy of SimpleProbeAction and renamed it into SimpleWConfigProbeAction. The new class will expect a single string configuration parameter, which should be set to the name of the top level SCOM workflow (i.e. calling monitor, or calling rule name). I added a method to load configuration from XmlReader and call this method from the constructor. Also, changed logging method to log the configure top level workflow name, so it’s seen in logs, which managed action is used in which workflow. In management pack code, a new probe action module type definition appears, which now include a configuration parameter.
private void LoadConfiguration(XmlReader configuration)
{
XmlDocument fullConfig = new XmlDocument();
fullConfig.Load(configuration);
TopLevelWorkflowName = fullConfig.GetElementsByTagName("TopLevelWorkflowName")[0].InnerText;
}
<ProbeActionModuleType ID="Maximus.Research.ManagedModules.SimpleWConfigProbeAction.ProbeAction" Accessibility="Public">
<Configuration>
<xsd:element minOccurs="1" name="TopLevelWorkflowName" type="xsd:string" />
</Configuration>
<OverrideableParameters>
<OverrideableParameter ID="TopLevelWorkflowName" Selector="$Config/TopLevelWorkflowName$" ParameterType="string" />
</OverrideableParameters>
<ModuleImplementation>
<Managed>
<Assembly>Maximus.Research.ManagedModules.Modules.DeployableAssembly</Assembly>
<Type>Maximus.Research.Modules.SimpleWConfigProbeAction</Type>
</Managed>
</ModuleImplementation>
<OutputType>System!System.PropertyBagData</OutputType>
<InputType>System!System.BaseData</InputType>
</ProbeActionModuleType>
Next step is to repeat all necessary wrappings into data source and unit monitor type. At each wrapping level, I propagate the TopLevelWorkflowName parameter in both configuration and overrideable parameters sections. Data source module will look like:
<DataSourceModuleType ID="Maximus.Research.ManagedModules.SimpleWConfigProbeAction.DataSource" Accessibility="Public">
<Configuration>
<xsd:element minOccurs="1" name="TopLevelWorkflowName" type="xsd:string" />
</Configuration>
<OverrideableParameters>
<OverrideableParameter ID="TopLevelWorkflowName" Selector="$Config/TopLevelWorkflowName$" ParameterType="string" />
</OverrideableParameters>
<ModuleImplementation>
<Composite>
<MemberModules>
<DataSource ID="DS_Scheduler" TypeID="System!System.SimpleScheduler">
<IntervalSeconds>60</IntervalSeconds>
<SyncTime />
</DataSource>
<ProbeAction ID="PA_SimpleProbeAction" TypeID="Maximus.Research.ManagedModules.SimpleWConfigProbeAction.ProbeAction">
<TopLevelWorkflowName>$Config/TopLevelWorkflowName$</TopLevelWorkflowName>
</ProbeAction>
</MemberModules>
<Composition>
<Node ID="PA_SimpleProbeAction">
<Node ID="DS_Scheduler" />
</Node>
</Composition>
</Composite>
</ModuleImplementation>
<OutputType>System!System.PropertyBagData</OutputType>
</DataSourceModuleType>
After creating new unit monitor type (it doesn’t have much deference with the one for Simple Action, just add configuration and pass is to nested data source module), I make the same set of agent task, rule, and monitor for the new managed module with the parameter. In each template, I configure template display name as a value for the TopLevelWorkflowName parameter. When completed and deployed, it’s expected to see two different managed module instances to be created.
And here the results:
[7e8a9679-1c8f-40d1-a75f-9efa08f44b4d]:[not loaded]:[19:32:17]: SimpleProbeAction class instance is created. Host process PID: 9688; Managed thread: 16
[13cdecd5-4109-4c50-b00b-0e43a06e9839]:[not loaded]:[19:32:17]: SimpleProbeAction class instance is created. Host process PID: 9688; Managed thread: 8
[7e8a9679-1c8f-40d1-a75f-9efa08f44b4d]:[Simple Probe Action with Parameter Rule]:[19:32:17]: Configuration is loaded.
[13cdecd5-4109-4c50-b00b-0e43a06e9839]:[Simple Probe Action with Parameter Unit Monitor]:[19:32:17]: Configuration is loaded.
[13cdecd5-4109-4c50-b00b-0e43a06e9839]:[Simple Probe Action with Parameter Unit Monitor]:[19:32:17]: Entering Start; Managed thread: 6.
[13cdecd5-4109-4c50-b00b-0e43a06e9839]:[Simple Probe Action with Parameter Unit Monitor]:[19:32:17]: First data item requested.
[7e8a9679-1c8f-40d1-a75f-9efa08f44b4d]:[Simple Probe Action with Parameter Rule]:[19:32:17]: Entering Start; Managed thread: 5.
[7e8a9679-1c8f-40d1-a75f-9efa08f44b4d]:[Simple Probe Action with Parameter Rule]:[19:32:17]: First data item requested.
[13cdecd5-4109-4c50-b00b-0e43a06e9839]:[Simple Probe Action with Parameter Unit Monitor]:[19:32:56]: Entering OnNewDataItems; Managed thread: 20
[13cdecd5-4109-4c50-b00b-0e43a06e9839]:[Simple Probe Action with Parameter Unit Monitor]:[19:32:56]: Received 1 inbound data items of System.TriggerData type.
[13cdecd5-4109-4c50-b00b-0e43a06e9839]:[Simple Probe Action with Parameter Unit Monitor]:[19:32:56]: No shutdown in progress.
[13cdecd5-4109-4c50-b00b-0e43a06e9839]:[Simple Probe Action with Parameter Unit Monitor]:[19:32:56]: Competed output data item.
[13cdecd5-4109-4c50-b00b-0e43a06e9839]:[Simple Probe Action with Parameter Unit Monitor]:[19:32:56]: Next data item requested.
[7e8a9679-1c8f-40d1-a75f-9efa08f44b4d]:[Simple Probe Action with Parameter Rule]:[19:32:56]: Entering OnNewDataItems; Managed thread: 6
[7e8a9679-1c8f-40d1-a75f-9efa08f44b4d]:[Simple Probe Action with Parameter Rule]:[19:32:56]: Received 1 inbound data items of System.TriggerData type.
[7e8a9679-1c8f-40d1-a75f-9efa08f44b4d]:[Simple Probe Action with Parameter Rule]:[19:32:56]: No shutdown in progress.
[7e8a9679-1c8f-40d1-a75f-9efa08f44b4d]:[Simple Probe Action with Parameter Rule]:[19:32:56]: Competed output data item.
[7e8a9679-1c8f-40d1-a75f-9efa08f44b4d]:[Simple Probe Action with Parameter Rule]:[19:32:56]: Next data item requested.
[49c46f7c-95a5-42d4-b7b5-3de5712d183d]:[not loaded]:[19:34:11]: SimpleProbeAction class instance is created. Host process PID: 1308; Managed thread: 11
[49c46f7c-95a5-42d4-b7b5-3de5712d183d]:[Simple Probe Action with Parameter Agent Task]:[19:34:11]: Configuration is loaded.
[49c46f7c-95a5-42d4-b7b5-3de5712d183d]:[Simple Probe Action with Parameter Agent Task]:[19:34:11]: Entering Start; Managed thread: 5.
[49c46f7c-95a5-42d4-b7b5-3de5712d183d]:[Simple Probe Action with Parameter Agent Task]:[19:34:11]: First data item requested.
[49c46f7c-95a5-42d4-b7b5-3de5712d183d]:[Simple Probe Action with Parameter Agent Task]:[19:34:11]: Entering OnNewDataItems; Managed thread: 11
[49c46f7c-95a5-42d4-b7b5-3de5712d183d]:[Simple Probe Action with Parameter Agent Task]:[19:34:11]: Received 1 inbound data items of BaseData type.
[49c46f7c-95a5-42d4-b7b5-3de5712d183d]:[Simple Probe Action with Parameter Agent Task]:[19:34:11]: No shutdown in progress.
[49c46f7c-95a5-42d4-b7b5-3de5712d183d]:[Simple Probe Action with Parameter Agent Task]:[19:34:11]: Competed output data item.
[49c46f7c-95a5-42d4-b7b5-3de5712d183d]:[Simple Probe Action with Parameter Agent Task]:[19:34:11]: Entering Shutdown; Managed thread: 5.
[49c46f7c-95a5-42d4-b7b5-3de5712d183d]:[Simple Probe Action with Parameter Agent Task]:[19:34:11]: shutdown is set to True.
In which:
- Lines 1 and 2, two managed modules created. It’s not known yet, which one is for rule or monitor, as their configurations are not loaded yet.
- Lines 3 and 4, configuration is loaded, so it’s known now that 7e8a9679-1c8f-40d1-a75f-9efa08f44b4d is for the rule, and 13cdecd5-4109-4c50-b00b-0e43a06e9839 is for the monitor.
- Lines 5 to 18 are normal cycle as already seen for the module without configuration, but now it’s doubled.
- Lines 19 to 29 are for the task. Module is created, started, got trigger data item, and then shut down.
Next experiment phase is to start changing monitor and rule configuration, to make both configuration identical. Note, that I’m going to change both configuration to use the same value, despite the same goal could be achieved by editing just one configuration. The reason behind this is to also explore single module configuration change cycle. I’m using the “Just Module” value, and first apply override to the monitor:
[13cdecd5-4109-4c50-b00b-0e43a06e9839]:[Simple Probe Action with Parameter Unit Monitor]:[10:00:56]: Next data item requested.
[50a9a8e1-39ec-4a48-9773-e7112674597f]:[not loaded]:[10:01:01]: SimpleProbeAction class instance is created. Host process PID: 9688; Managed thread: 25
[50a9a8e1-39ec-4a48-9773-e7112674597f]:[Just Module]:[10:01:01]: Configuration is loaded.
[13cdecd5-4109-4c50-b00b-0e43a06e9839]:[Simple Probe Action with Parameter Unit Monitor]:[10:01:01]: Entering Shutdown; Managed thread: 33.
[13cdecd5-4109-4c50-b00b-0e43a06e9839]:[Simple Probe Action with Parameter Unit Monitor]:[10:01:01]: shutdown is set to True.
[50a9a8e1-39ec-4a48-9773-e7112674597f]:[Just Module]:[10:01:01]: Entering Start; Managed thread: 27.
[50a9a8e1-39ec-4a48-9773-e7112674597f]:[Just Module]:[10:01:01]: First data item requested.
[50a9a8e1-39ec-4a48-9773-e7112674597f]:[Just Module]:[10:01:56]: Entering OnNewDataItems; Managed thread: 20
[50a9a8e1-39ec-4a48-9773-e7112674597f]:[Just Module]:[10:01:56]: Received 1 inbound data items of System.TriggerData type.
The log above shows exactly the same flow as seen during module library upgrade. I.e. create a new instance, send shutdown signal to the old instance, continue with the new instance.
Now, let’s set the rule configuration to use the same configured value using the same object as override scope. The hope here is that SCOM will restore the cookdown, and just destroy one of the modules, leaving the only one behind. However, let the experiment run.
[50a9a8e1-39ec-4a48-9773-e7112674597f]:[Just Module]:[12:49:56]: Entering OnNewDataItems; Managed thread: 5
[50a9a8e1-39ec-4a48-9773-e7112674597f]:[Just Module]:[12:49:56]: Received 1 inbound data items of System.TriggerData type.
[50a9a8e1-39ec-4a48-9773-e7112674597f]:[Just Module]:[12:49:56]: No shutdown in progress.
[50a9a8e1-39ec-4a48-9773-e7112674597f]:[Just Module]:[12:49:56]: Competed output data item.
[50a9a8e1-39ec-4a48-9773-e7112674597f]:[Just Module]:[12:49:56]: Next data item requested.
[7e8a9679-1c8f-40d1-a75f-9efa08f44b4d]:[Simple Probe Action with Parameter Rule]:[12:49:56]: Entering OnNewDataItems; Managed thread: 34
[7e8a9679-1c8f-40d1-a75f-9efa08f44b4d]:[Simple Probe Action with Parameter Rule]:[12:49:56]: Received 1 inbound data items of System.TriggerData type.
[7e8a9679-1c8f-40d1-a75f-9efa08f44b4d]:[Simple Probe Action with Parameter Rule]:[12:49:56]: No shutdown in progress.
[7e8a9679-1c8f-40d1-a75f-9efa08f44b4d]:[Simple Probe Action with Parameter Rule]:[12:49:56]: Competed output data item.
[7e8a9679-1c8f-40d1-a75f-9efa08f44b4d]:[Simple Probe Action with Parameter Rule]:[12:49:56]: Next data item requested.
[7e8a9679-1c8f-40d1-a75f-9efa08f44b4d]:[Simple Probe Action with Parameter Rule]:[12:50:15]: Entering Shutdown; Managed thread: 33.
[7e8a9679-1c8f-40d1-a75f-9efa08f44b4d]:[Simple Probe Action with Parameter Rule]:[12:50:15]: shutdown is set to True.
[50a9a8e1-39ec-4a48-9773-e7112674597f]:[Just Module]:[12:50:56]: Entering OnNewDataItems; Managed thread: 34
[50a9a8e1-39ec-4a48-9773-e7112674597f]:[Just Module]:[12:50:56]: Received 1 inbound data items of System.TriggerData type.
[50a9a8e1-39ec-4a48-9773-e7112674597f]:[Just Module]:[12:50:56]: No shutdown in progress.
[50a9a8e1-39ec-4a48-9773-e7112674597f]:[Just Module]:[12:50:56]: Competed output data item.
[50a9a8e1-39ec-4a48-9773-e7112674597f]:[Just Module]:[12:50:56]: Next data item requested.
[50a9a8e1-39ec-4a48-9773-e7112674597f]:[Just Module]:[12:51:56]: Entering OnNewDataItems; Managed thread: 26
[50a9a8e1-39ec-4a48-9773-e7112674597f]:[Just Module]:[12:51:56]: Received 1 inbound data items of System.TriggerData type.
[50a9a8e1-39ec-4a48-9773-e7112674597f]:[Just Module]:[12:51:56]: No shutdown in progress.
[50a9a8e1-39ec-4a48-9773-e7112674597f]:[Just Module]:[12:51:56]: Competed output data item.
[50a9a8e1-39ec-4a48-9773-e7112674597f]:[Just Module]:[12:51:56]: Next data item requested.
And this worked exactly as expected! But let’s go through the log carefully.
- Lines 1-5, are one normal cycle loop for the monitor (which is was configured with “Just Module”).
- Lines 6-10, are the same normal cycle loop for the rule, which is still configured with the default “Simple Probe Action with Parameter Rule” value.
- Lines 11 and 12, this is the interesting part. SCOM Agent shuts down the managed module instance used in rule’s data source. From there, it either need to either re-create the module with the new configuration value, OR start re-using the existing module.
- Lines 13-22, with two scheduler intervals passed, there is not a single line from any other module instances, rather then the initial instance used for the monitor (same ID — 50a9a8e1-39ec-4a48-9773-e7112674597f — as in lines 1-5). This simply means, that SCOM Agent destroyed module instance used for the rule, and started using monitor’s module instance for the rule as well. This happened because both data sources (rule’s one and monitor’s one) have the same identical configuration.
This is a very important result. It tells, that SCOM Agent will apply cookdown not only when default values are set, but also if all overrides set configuration values same. In the first part of this article, I made an example, where decreasing frequency for some rules or monitors, can, in fact, cause more frequent polling, rather then decreasing the number of probes. This happens if these rules and monitors use the same shared data source and reconfiguration breaks cookdown. Therefore, the very first recommendation is to avoid too much overrides, if they can break cookdown (and introduce bigger motioning footprint). But the second recommendation, which can be made after this experiment, tells that overrides can be made without breaking cookdown, if they are made with the same parameter value(s) and applied to all rules and monitors, which share the same data source.
This is the end of the part 2.
Last part: https://maxcoreblog.com/2020/11/03/implementing-scom-managed-modules-part-3/
Max's blog on SCOM Authoring and more 
3 thoughts on “Implementing SCOM Managed Modules. Part 2.”