This post is part of a series on Service Manager PowerShell. Be sure to check out the Overview Page for all posts in this series.

Service Manager comes with two different PowerShell modules, the Administrator module and the Data Warehouse module. The Administrator module contains the cmdlets for working with the different work items and configuration items, and for performing administrative tasks within Service Manager. The Data Warehouse module is used for administering the data warehouse. Unless otherwise specified, the posts in this series will be referring to the Administrator module, and its cmdlets.

Loading the Service Manager Modules

There are a few ways that you can access the Service Manager module. First, in the Service Manager console, if you are in the Administration work space, you can click on Start PowerShell Session. Or on a machine with the Service Manager console installed you can go to Start > Microsoft System Center then click on Service Manager Shell. Either one of these will open a PowerShell prompt with both of the Service Manager modules loaded. This is fine for running short commands, but for more advanced scripts I prefer using the PowerShell Integrated Scripting Environment (ISE).

*PowerShell Tip – Execution Policy
The Windows PowerShell execution policy determines whether or not you can run scripts. By default this is set to “Restricted” which prevents all scripts from running. You can use the Set-ExecutionPolicy cmdlet to change this level. Typically you want to keep this set to the highest level possible that still allows you to perform your work. I typically recommend setting it to RemoteSigned. This allows you to execute all scripts you created locally, but requires a digital signature from a trusted publisher for any downloaded scripts. For more information on execution policies see about_Execution_Policies on TechNet.

Using PowerShell ISE

When using PowerShell ISE the Service Manager PowerShell modules will not be automatically loaded. You must load them manually. Typically to load a PowerShell module you enter Import-Module and the module name. However, this only works if the module is installed in the path listed in the environment variable PSModulePath. Unfortunately, the Service Manager modules are not installed using this path, so you must specify the full path to the modules psd1 file. The Service Manager PowerShell modules are installed in the Service Manager install folder. The default directory is “C:Program FilesMicrosoft System Center 2012Service Manager” or “C:Program FilesMicrosoft System Center 2012 R2Service Manager” depending on your version. To make things even more interesting the the Data Warehouse module is located at the top level of this folder, but the Administrator module is located in the subfolder PowerShell. The commands to load the modules using the default R2 paths are listed below.

As you can see this can cause problems because the default path changes between versions, and you don’t always install programs to the C drive or the default directory. Luckily, Service Manger stores its install path in the registry key InstallDirectory located under HKEY_LOCAL_MACHINESOFTWAREMicrosoftSystem Center2010Service ManagerSetup. So to make a script more transportable you can write the value this key to a string variable and concatenate the psd1 file to the end of it.

To confirm that the modules have loaded you can enter the command Get-Module. You should see an entry named System.Center.Service.Manager for the Administrator module and Microsoft.EnterpriseManagement.Warehouse.Cmdlets for the Data Warehouse module.

 

In some cases if you run the same script in the same session it can cause an error message because it is trying to load a module that is already loaded. To prevent this you can use an If statement to check and see if the module is loaded. If it is not, then it will load it. If it is, then it will just continue on.

*PowerShell Tip – Automatically Loading Modules
PowerShell and PowerShell ISE both let you create profiles. A profile is a script that runs automatically when you open the console. You can create a profile to automatically load the modules for you every time you open PowerShell.  Scripting Guy, Ed Wilson, has a great article on detailing the ins and outs of creating a PowerShell ISE profile, so I won’t go into much detail here. But below is an example of a script you can run to create a profile that will load the Service Manager modules for you. It uses the same commands as you just saw, but with some additional checks rolled in, just incase. All you need to do is open PowerShell ISE, copy and paste the code below into the script window, and execute. Once your command completes, close and reopen PowerShell ISE. Then enter Get-Module and confirm that the Service Manager modules are loaded.

 

Connecting to Service Manager Management Server

Unless you are on the Service Manager Management Server, the Service Manager cmdlets will not know which server to run against. To let them know which server to connect to, you can do one of two things. You can add the –ComputerName parameter to end every command you enter specifying your manager server. As you can imagine, this would get old pretty quick. Your other option is to create a Management Group Connection, using the New-SCManagementGroupConnection cmdlet. When you use this command, it will maintain the connection to your Service Manager environment as long as you keep the session open. This means you just run this once, and you don’t have to specify the computer name for any of the other commands in your script.

Like with the Import-Module you can also use a registry key to quickly return the Service Manager server. However, keep in mind that this key is user specific, and they must have connected to the Service Manager server in order for this key to be populated.

To confirm that you have an active connection you can use the Get-SCManagementGroupConnection cmdlet.

mggroup

 

Now that you have loaded the Service Manager modules and connected it to your Service Manager environment, you are ready to start using them. The next post will cover how to query and return information related to the different work items. And be sure to check the Overview Post for more content in this series.