Most of you work with the Integration Pack for System Center Service Manager to automate Service Manage in Orchestrator. Orchestrator and Service Manager are a “dream team”:
With the integrated Connector for Orchestrator you can Trigger Runbooks directly for Service Requests.
With the Activities from Integration Pack for Service Manager you can easily automate common tasks Service Manager.
If you have PowerShell in
- Azure Automation
- Service Management Automation
- Remote source scripts in Gridpro
- Request Management for WAP
- and many others
you can use the PowerShell Moduls Service Manager cmdlets (https://docs.microsoft.com/en-us/system-center/scsm/sm-cmdlets?view=sc-sm-2019) or SMlets (https://github.com/SMLets/SMLets/releases/tag/v1.0, https://www.powershellgallery.com/packages/SMLets/1.0.2016.0).
I even use the SMlets in the “Run .Net Script” Activities in Orchestrator because you can have more complex and powerful automation with them.
SCSM have a native cmdlets which are installed with SCSM console. Some of native SCSM cmdlets use different from SMLets names of the cmdlet.
The main difference between SMLets and native cmdlets is that native cmdlets target to wotk with SDK object and methods. Almost all native cmdlets return SDK object along with adapted PS object. So, if you want to use native cmdlets with full strange you must learn about SCSM SDK. Second effect of this is another way to update objects.
The table here (https://blog.scsmsolutions.com/2012/02/reference-between-smlets-and-scsm-2012-native-cmdlets/) shows the SMLets cmdlets and corresponding native cmdlet if there are any.
The SMlets are much more powerfull.
In this blog post (https://blog.scsmsolutions.com/2019/12/new-version-of-the-smlets-released/) the author Anton Gritsenko states the version released on Christmas is the last release of the SMLets, no more “feature” releases expected.
Thank you, Anton for your great work!