In this post, I’ll discuss how to perform administrative tasks in Service Management Automation that will be useful to keep the service running well. I will cover how purging of data happens, the use of system runbooks, and configuration tasks that are available.
Purging in SMA:
Purging of data that is no longer needed is an important task that needs to be run in order to keep the system running well and ensure that performance stays within expected levels. SMA has a built in SQL Server Agent purging job that runs every fifteen minutes to remove old jobs and deleted runbooks from the database.
The SMA Database Purge Job has a step called SMA Database Purge Next Batch that calls the stored procedure SMA.Purge.PurgeNextBatch that implements the functionality to remove jobs older than the specified days (30 is the default) or where there are more job records than the total allowed (100,000 is the default).
This stored procedure calls the PurgeJobs SP that removes the jobs and then calls PurgeJobContext that removes the related job context data. Lastly, runbooks are removed that were deleted from the system and don’t have any active jobs associated with them. You can review these stored procedures in SQL Studio Management as shown below if you want to fully understand how they work.
The DiscoverAllLocalModules system runbook is started when the first web service is added to SMA so that all native windows modules on the first runbook worker are imported into SMA so that they can be used during authoring of your runbooks. You can see these modules activities when you insert an activity from the authoring experience.
You can track the progress of importing these modules into the system by looking at the job created when the runbook worker processes the request. If a module fails to import for some reason you can identify the error and manually import this module into the system.
The SetAutomationModuleActivityMetadata system runbook is called each time a module is imported into SMA, to extract the metadata about each activity in the module like the description, help URI, and parameters so that they are available when selecting the activity during authoring of a runbook.
SMA Administrative tasks:
Below are the list of additional administrative tasks available in SMA.
– Gets the expiration date of SMA if it is an evaluation version.
– This cmdlet is used to convert from an evaluation version of SMA to a retail version.
An event is logged to the event log by the runbook service when the evaluation period of 180 days is over. You can then use Set-SmaLicense to enter in the product key and you will be able to start the runbook service again.
If you are looking for a solution to keep all of your runbook workers configured with the same modules and software packages, you could use the PowerShell Desired State Configuration capabilities as outlined on a
by Michael Rueefli.