The ScsmPx module facilitates automation with Microsoft System Center Service Manager by auto-loading the native modules that are included as part of that product and enabling automatic discovery of the commands that are contained within the native modules. It also includes dozens of complementary commands that are not available out of the box to allow you to do much more with your PowerShell automation efforts using the platform.
The ScsmPx module is installed with a single PowerShell command. Note that you can update the ScsmPx module to the latest version at any time simply by running this command again.
While installation via the online script is preferred, you can also manually install this module if you prefer. Both the ScsmPx module and the SnippetPx module that it is dependent on are hosted on GitHub at github.com/KirkMunro. I strongly recommend using the automated installation method though.
There are 157 commands available in the ScsmPx module today, and 116 cmdlets in the native modules, offering a total of 273 commands to make Microsoft System Center Service Manager automation easier. To see a list of all of the commands that are available in the ScsmPx and native modules, invoke the following commands:
Note that when you first run these commands, there will be a short delay as the module is loaded into the PowerShell session (unless you have disabled module auto-loading in your environment, in which case you will have to invoke the Import‑Module cmdlet first to manually import the ScsmPx module and the native SCSM modules that it loads for you).
The first command will return a list of commands that are included in the native modules that ship with Microsoft System Center Service Manager. The second command will return a list of commands that are included in the ScsmPx module. Note that all ScsmPx module commands start with the ScsmPx noun prefix.
To see a list of all incidents that you have in your environment, invoke the following command:
This data represents individual instances of the System.WorkItem.Incident class, and it does not identify any of the objects that are related to those instances. Commands invoked like this allow for very efficient management of Microsoft System Center Service Manager object data. If you want to work with more complex data that includes multiple related instances combined into a single view, you can request a specific view of that data instead by using the -View parameter. For example, to see a more user friendly view of the incidents in your environment you could invoke the following command instead:
This data provides the same information that you see when you access the corresponding "All Incidents" view in the management console. Note that you cannot apply filters when you are looking up data using a view. In those cases, the filters that are defined as part of the view are used.
To see what you can do with that data once you have it, have a look at the other ScsmPxIncident commands by invoking the following command:
This identifies that there are other commands that work with incidents. To use these commands to modify incidents, you can leverage the pipeline. For example, to automatically close any incidents that have been resolved for more than 7 days, you could use the Set‑ScsmPxIncident command in the following script:
That demonstrates one simple example to a common problem that these commands can help resolve with little effort. Between PowerShell scripts, PowerShell workflows, Microsoft System Center Service Manager workflows, Microsoft System Center Orchestrator workflows, and now the new Service Management Automation (SMA) feature of Microsoft System Center Orchestrator, there are plenty of opportunities to use PowerShell commands to automate Microsoft System Center Service Manager. Experiment with the other commands in the ScsmPx module and see what solutions you can come up with.
Want to report a bug or suggest a new feature? Having problems with ScsmPx? Open a new issue at https://github.com/KirkMunro/ScsmPx/issues and we’ll help you sort it out.