As you begin to interact with System Center Service Manager, you will without any doubt find yourself scratching your head trying to figure out why on earth there is not one, but two PowerShell modules available for this component.
Could it be that the tool is so complex that we needed to add yet more commands to simplify our life? Is it possibly the case that one of the modules is no longer really relevant and we can just focus on one of these? Is it okay to install both on the same server? Why would I ever need both?
A little history is a good start to understand the present, and in the case of Service Manager and PowerShell, history is very important. At the time of the 2012 RTM release Service Manager was the ugly duckling in the System Center family as it did not have its own in box PowerShell module. However all was not lost, as shortly after the public launch of Service Manager 2010, Patrik Sundqvist (GridPro) along with Travis Wright, the then-Microsoft project manager with responsibility for Service Manager, launched an open source module on Codeplex.com called SCSM PowerShell Cmdlets (or SMLets for short) to fill the gap. The module is still maintained, but not as actively, and it works extremely well with all the releases of Service Manager, to the current (as of time of writing) 2012 R2 release. This module is by designation open source; support is through the community since this module has enjoyed a long headstart, and with it, a large user base.
The second module to appear on the scene, is the inbox module, simply called Service Manager Shell (or by its full name: system.center.service.manager). This is the newest of the modules to be offered for Service Manager. It is part of the inbox offering, so it is fully supported by Microsoft.
A we have grown to expect, PowerShell modules generally have no problem coexisting with each other, and these two modules enjoy this flexibility. In reality they currently compliment each other – there are some areas in the Service Manager product better covered by a particular module. Most of the new development work does appear to be occurring with the inbox module, but not at a pace at which one would yet consider ignoring SMLets.
The inbox module in the 2012 R2 release now contains 122 commandlets, while the current SMLets version contains 109 commandlets.
If you are still wondering whether you even need to look at these modules, consider for a moment the ease of closing all resolved incidents beginning with a title of Exchange and have been untouched for three days.
Get-SCSMIncident –Title "Exchange%" –Status Resolved –InactiveFor 3.00:00:00 | Set-SCSMIncident –Status Closed –Comment "Closed due to inactive period"
After all this you might be surprised to learn that a third module is available for Service Manager, which is also delivered as part of the inbox solution. This module is focused on the Data Warehouse functions of Service Manager. The full name of this module is Microsoft.EnterpriseManagement.Warehouse.Cmdlets and is installed by default with the Service Manager Data Warehouse services. The module exposes 27 commandlets, mostly focused on the management of the jobs in the warehouse.
Generally one of the primary reasons for choosing to leverage the PowerShell modules will be to assist in the automation of a procedure, either as part of a integrated Service Manager workflow or as part of an external orchestration. Regardless, you will want to ensure that your methods are somewhat future proofed – especially if you also expect to be sharing the management of these methods with others, or if they play a critical role in deliver of a business service. Currently a lot of my existing modules, and even many of my newer modules, are still created using SMLets, However, I am beginning to make a conscious effort to leverage the inbox commands where possible – and it is not always possible – to address my automation goals.
Choice is good! So for now go spoil yourself and enjoy the choices you have available.