SMA Modules: Extracted Activity Data "Empty" or Missing

Service Management Automation is young enough to have a number of quirks that can be frustrating to get around. One surprising quirk has been with SMA Module Activity Data (i.e. functions) to not appear on all machines consistently.

The extraction of Metadata from an imported module is a secondary activity. It’s normal for a delay to exist between importing a module and the internal activities / functions becoming visible. The problem I am referring to affects development servers where modules are deleted and re-imported. The issue also manifests itself with new activities failing to appear on some servers and not others.

After starting to become superstitious about it all, I’ve come up with a working theory that seems to resolve this reoccurring issue.

SMA Module Structure

SMA modules are PowerShell modules. The name of the module is the same as the folder it resides with (which is also zipped for import into Service Management Automation). Modules are advised to have a PowerShell definition file. The definition will list the elements to export from within the PowerShell module along with core information about the module itself.

Those from a packaging background would instinctively guess that the module GUID is the unique identifier of the SMA module. It turns out this isn’t correct. SMA will generate its own Module ID each time an SMA module is imported – the module ID within a PSD file is redundant.

When Service Management Automation Modules are imported, a series of tables link each parameter object with back to the imported module. More specifically, Activities / Functions hang off the modules versions table. No doubt the logic is that each version of the same module could have different functions, each with different parameters.

Table	Purpose	Linked Data with Previous Table
Core.ActivityParameters	Lists each parameter object	ActivityKey
Core.ActivityParameterSets	Groups parameter objects	ActivityKey
Core.Activities	Lists functions to Module versions	ModuleVersionKey
Core.ModuleVersions	Creates a unique “version” entry to link the version of the module to the module name.	ModuleKey
Core.Modules	Creates a module listing and key each time a module is imported.

What is odd is that every module, regardless of versions specified within their PSD file is being imported as version “1” within the SMA database. I suspect this is where the logic is falling down.

When I import a module called “Rhubarb” containing two activities, and later import a new version of the “Rhubarb” module with 3 or 4 activities, as the system sees both modules as “Rhubarb v1”, the activity extraction process seems to be defaulting to the core activities that had been extracted in the earlier release of the module. Neither an alteration of the Module GUID or version (within the PSD definition) file will force SMA to find newly added activities.

What does work every time is changing the name of the module files & folder. With this example I appended “_1.00b” to the folder name & renamed the psm & psd files to match. I also updated the PSD accordingly.

It doesn’t hurt to include a version in the name of module being created but it more likely highlights the need to develop SMA modules on dedicated development systems that can be rebuilt easily.

The last point I’d make is that if you do work off a dedicated development, promoting modules with PowerShell is much faster than using the web interface. Two lines of code are all that are required to reimport a modified module.

[[powershell]]
Remove-SmaModule -Name "SCCM_1.00b" -WebServiceEndpoint "https://localhost"

Import-SmaModule -WebServiceEndpoint "https://localhost" -Path "D:\Modules\SCCM_1.00b.zip"
[[/powershell]]