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.
You can read how to configure purging on the TechNet article http://technet.microsoft.com/en-us/library/dn469633.aspx. The following SQL Server Agent Job, created during the installation of SMA, is used for purging data.
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.
You can retrieve the current settings for purging by running the SMA PowerShell cmdlet Get-SmaAdminConfiguration as shown below.
In order to change these values you use the Set-SmaAdminConfiguration cmdlet.
You can read additional information on purging as well as the other settings available in this cmdlet on http://technet.microsoft.com/en-us/library/dn502591(v=sc.20).aspx
SMA System Runbooks:
SMA ships with two system runbooks as shown in the below image. You can read more about these on http://technet.microsoft.com/en-us/LIBRARY/dn443762.aspx
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.
Get-SmaLicense – Gets the expiration date of SMA if it is an evaluation version.
Set-SmaLicense – 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.
Get-SmaRunbookWorkerDeployment – Gets all of the runbook workers registered in the runbook worker deployment.
New-SmaRunbookWorkerDeployment – this cmdlet is used to add additional runbook workers to the runbook worker deployment.
As you can see from the above examples, all administrative tasks in SMA are performed using the PowerShell cmdlets (you can learn more about these on http://blogs.technet.com/b/orchestrator/archive/2014/03/11/sma-capabilities-in-depth-the-sma-powershell-module.aspx). This allows you to script out these tasks according to your processes and even to be called within SMA as runbooks, since the SMA cmdlets ship for use within SMA!
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 ScriptCenter contribution by Michael Rueefli.
For monitoring and troubleshooting SMA, please have a look at the blog post on http://blogs.technet.com/b/orchestrator/archive/2014/03/18/monitoring-and-troubleshooting-in-service-management-automation.aspx to enable you to keep the service healthy.
Hopefully this will allow you to manage all of the administrative tasks within SMA and ensure you have a well running deployment.