SCSM PowerShell: Get Relationships

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.

In the previous posts, we looked at returning work item and configuration item information with the Get-SCSMClassInstance cmdlet. In one of the examples, we returned all of the properties related to an Incident. You may have noticed, when running this command, that certain items were not returned. Most notably are the assigned to user and the affected user. It also did not return any related configuration items, work items, or activities. The reason these were not returned, is because they are not properties. They are related items. In order to find this you must first find the relationship, then you can return the details of the object.

Determining the Relationship

Just like with class instances, if you want to return a related object, you need to know what the relationship is. As with most things in Service Manager, there are multiple ways that you can determine the relationship. The examples below use the Get-SCSMRelationship cmdlet to determine the relationship. Example 1 is using the Display Name of the relationship. In this case I knew the name of the relationship, and was able to return it in my command. If you are unsure of the relationship you can use a wildcard like in example 2. You can also search by using the Source of Target class. However, you need to be careful with this. If, for example, you ran this command against the Incident class (System.WorkItem.Incident), all that would be returned is the Primary Owner relationship. This is because it is the only one unique to the Incident class. To find the affect user you would need to search on the base System.WorkItem class. For this reason, I generally stick to searching by name.

# Example 1: Using the Display Name
Get-SCSMRelationship -DisplayName "Affected User"
 
# Example 2: Using a Wildcard
Get-SCSMRelationship -DisplayName "*User*" 
 
# Example 3: Using the Source 
Get-SCSMRelationship -Source (Get-SCSMClass -Name System.WorkItem)

One way to determine the relationship name is to look at the history of an item in the console. If you look at the item history you will see all relationship changes. The display name of the relationship will be present under the relationship class column.

For more information in determining classes, I suggest checking out this post by Marcel Zehner. He created an excel sheet with all of the different relationship types in Service Manager.

There is one more thing to keep in mind with the Get-SCSMRelationship cmdlet. As with other things in SCSM, multiple relationships can have the same display name. So after finding the relationship using the methods above, it is best to use the Name parameter since this is a unique value. However, for some reason the Get-SCSMRelationship cmdlet does not output the name by default, so you should add “| FT DisplayName, Name” to the end of your command to determine the name.


# Step 1: Determine the relationship
Get-SCSMRelationship -DisplayName "Affected User"
 
# Step 2: Find the name
Get-SCSMRelationship -DisplayName "Affected User" | FT DisplayName, Name
 
# Step 3: Using the name parameter save the relationship to a variable
$rel = Get-SCSMRelationship -Name "System.WorkItemAffectedUser"

Finding the Related Objects

After determining the relationship, you can use the methods in Get-SCSMClassInstance cmdlet to return the related objects. There are two different methods to find these, GetRelatedObjectsWhereSource and GetRelatedObjectsWhereTarget. You need to use the one where the class of the object you are returning from Get-SCSMClassInstance matches either the source or the target. The example below show how to find the affected user of the incident. Since Get-SCSMRelationship showed that the source is System.WorkItem, we’ll use the GetRelatedObjectsWhereSource method.


# Get the relationship
$rel = Get-SCSMRelationship -Name "System.WorkItemAffectedUser"
 
# Get the incident
$IR = Get-SCSMClassInstance -Class (Get-SCSMClass -Name System.WorkItem.Incident) | ? {$_.ID -eq "IR3570"} 
 
# Use the methods to return the object
$IR.GetRelatedObjectsWhereSource($rel.ID)

When you run the command above it will output the EnterpriseManagementObject, which is typically the display name of the object. In this case it would be the name of the Affected User. However, the EnterpriseManagementObject is not just a string value. It contains multiple sub properties of the related object. As with everything else, you never want to go strictly off the display name. So if you add “.EnterpriseManagementObject.id.GUID” to the end of the command it will return the unique GUID of the object. If you save that in a variable, you can then use it with the Get-SCSMClassInstance to return all of the information about the object.

# Get the relationship
$rel = Get-SCSMRelationship -Name "System.WorkItemAffectedUser"
 
# Get the incident
$IR = Get-SCSMClassInstance -Class (Get-SCSMClass -Name System.WorkItem.Incident) | ? {$_.ID -eq "IR3570"} 
 
# Use the methods to return the object GUID and save it to a variable
$AffctUsr = $IR.GetRelatedObjectsWhereSource($rel.ID).EnterpriseManagementObject.id.GUID
 
# Return the details of the related object
Get-SCSMClassInstance -ID $AffctUsr

This same logic can be applied to the assigned to user, created by user, related work items, affected configuration items, etc. You just need to know the relationship you want to find.

Finding the Related Object by Target

Using the same logic as the previous example you can easily find the activities contained within a Change Request.

# Get the relationship
$rel = Get-SCSMRelationship -Name "System.WorkItemContainsActivity"
 
# Get the change request
$CR = Get-SCSMClassInstance -Class (Get-SCSMClass -Name System.WorkItem.ChangeRequest) | ? {$_.ID -eq "CR823"} 
 
# Use the methods to return the object GUID and save it to a variable
$Act = $CR.GetRelatedObjectsWhereSource($rel.ID).EnterpriseManagementObject.id.GUID
 
# Return the details of the related object
Get-SCSMClassInstance -ID $Act

The example above returns the activities contained within the change request CR823. But what if you have the review activity, and you want to return the change request it belongs to? In that case all you would need to do is to change your script to use the GetRelatedObjectsWhereTarget method.

# Get the relationship
$rel = Get-SCSMRelationship -Name "System.WorkItemContainsActivity"
 
# Get the review activity
$RA = Get-SCSMClassInstance -Class (Get-SCSMClass -Name System.WorkItem.Activity.ReviewActivity) | ? {$_.ID -eq "RA825"} 
 
# Use the methods to return the object GUID and save it to a variable
$WI = $RA.GetRelatedObjectsWhereTarget($rel.ID).EnterpriseManagementObject.id.GUID
 
# Return the details of the related object
Get-SCSMClassInstance -ID $WI

This same logic would apply if you wanted to find all of the work items a user is assigned to, or any other type of relationship.

This section showed how to find different related objects. The next few sections will cover how to update, create, and remove relationships and work items. And be sure to check the Overview Post for more content in this series.

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.

In the previous post we looked at getting work item information using the Get-SCSMClassInstance. This post will expand upon that to include configuration items. Like work items, configuration items are classes in Service Manager, so they also use the Get-SCSMClassInstance cmdlet.

Tips to Find the Class

Just like with the work items you need to start out by determining the name of the class for the item you want to return. However, unlike work items configuration item classes can be a little more difficult to find. This is especially true if you have synced your Operations Manager management packs into Service Manager. For example, in a standard Service Manager environment if I run the Get-SCSMClass cmdlet for any classes that have a display name that contains “computer”, 22 different classes are returned. If that is not bad enough, I ran this same command in a Service Manager environment where I had imported the Operations Manager management packs, and it returned 79 different classes. To be completely honest, sometimes it just takes some trial and error to find the correct class. However, there are a few tricks you can use to help find the correct class.

One way to find the class name is by looking at the views in Service Manager. If you right click on a view and click edit view, it will open the view editing form. If you scroll down to the Criteria section, you will see the display name of the class in the Search for objects of a specific class box.

Another option is to search for classes based on the management pack. For example, if I search for classes that contain “SQL” in their display name, 96 different classes are returned. But if you look at the data returned you’ll notice the column ManagementPackName. By filtering down my results to only include results in the “Microsoft.SQLServer.Library” management pack, I can reduce the number I have to look through to 20.

One last thing you can do to try and determine the configuration item class, is search the default configuration item class (System.ConfigItem) for the item. For example, say you want to find the class for the computer, and you know that there is a computer with the display name of DC01. I can run the Get-SCSMClassInstance to return all configuration items with a display name of DC01. Then, in the output there will be property called “#FullName”. This property is composed of the class name, then a colon followed by the items internal name. Depending on your connectors and how many items you have in your CMDB, you still may receive multiple items returned, but you will be much closer to finding your class.

# Find a CI's Class 
$CIclass = Get-SCSMClass -Name System.ConfigItem 
Get-SCSMClassInstance -Class $CIclass | ?{$_.DisplayName -eq "DC01"} | FT DisplayName, "#FullName" -AutoSize

*PowerShell Tip – You may have noticed in the command above, that I put #FullName in quotes. This is because the hash (#) symbol marks the start of a line comment. Therefore anything after the hash would be ignored. By placing it in between quotes, PowerShell sees it as a string and treats like any other string.

*PowerShell Tip – Sometimes you will notice that PowerShell cuts off the end of the output. This can happen when you return long strings like the #FullName property often is. To prevent this, you have use the AutoSize parameter with the FT cmdlet. The AutoSize parameter will calculate the column sizes and adjust them to best fit your screen. If you are still unable to fit the full output on your screen, you can also use the Wrap parameter to allow word wrapping of the results. For more information on formatting output see the TechNet article Using Format Commands to Change Output View.

Bonus Script

I often find it useful to know what classes a class inherits. To find this, I have written a Function that will parse backwards to find all inherited classes, using the Base property for a class. In the example below, I am using it find all of the classes that the class “Microsoft.Windows.Computer” inherits.

PowerShell
Function GetClassBase($classId)
{
    $class = Get-SCSMClass -Id $classId
    $collection += New-Object PSObject -Property @{Name=$class.Name; DisplayName=$class.DisplayName}
    If($class.Base)
    {
        GetClassBase $class.Base.Id.Guid
    }
    return $collection
}
 
$class = Get-SCSMClass -Name Microsoft.Windows.Computer
GetClassBase $class.Id | FT DisplayName, Name -au

This post demonstrated some tips on how to determine configuration item classes. Be sure to check the Overview Post for more content in this series.

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.

If you look at the Service Manager cmdlets, you will notice that there are no cmdlets along the lines of Get-Incident or Get-ServiceRequest. So you may ask yourself, how do I find this information? And the answer is, by using the Get-SCSMClassInstance cmdlet. The Get-SCSMClassInstance cmdlet can be used to return any work item or configuration using either the item’s ID or Class. The ID parameter is not referring the ID you see in the console, like SR1234 or IR429. It is referring to the internal GUID of the item. Since I don’t commonly make a habit of memorizing 128-bit integers, I tend to find the Class parameter much easier to use. You can use the Class parameter to query against all items in a specific class. Then you can use filters to get the items you want. In our examples here we will mainly be using the Class parameter.

Before diving into the Get-SCSMClassInstance cmdlet I want to give a quick recap on how Service Manager classifies things. All work items and configuration items inside of Service Manager are members of a class. Incident is a class, Service Request is a class, Computers is a class, and on. Also, many classes inherit from parent classes. For example, Incident and Service Request are sub-classes under the Work Items class. Configuration items work the same way, but we will cover those in a later section.

Finding the Class

In order to return a class instance, you must first take a step back and find what class you want. When dealing with Work Items this is usually pretty easy to do. They will typically fall into one of the major ITIL roles; Incident, Service Request, Change Request, Problem, Release Records, and Activities. To get the class we’ll use the Get-SCSMClass cmdlet. For example to get the Incident class we use the command.

Get-SCSMClass -Name System.WorkItem.Incident

So how did I know to use the name “System.WorkItem.Incident”? To tell you the truth, I’ve been working with these enough, that I have it memorized. However, there are hundreds of different classes, and I admit I don’t have all of them committed to memory. To find the class you want, you could enter Get-SCSMClass, without any parameters, and dig through all of the results until you find the one you want. Another option is, since you must likely know the name of the class you want, you can use the DisplayName parameter with wildcards. This will greatly reduce the number of results. For example to find the Incident class I used the command:

Get-SCSMClass -DisplayName *incident* | FT DisplayName, Name

This returned a short list of all classes with the word “incident” in the display name. From here I can easily find the incident work item class’s name and use that in my command. You may have noticed that I used the Name parameter with System.WorkItem.Incident instead of the DisplayName parameter with just Incident. This is because the display name is not a unique field. You can have two classes with the same display name. For this reason, always use the Name parameter in your final scripts.

Querying Work Items

Now that you have your class you can use the Get-SCSMClassInstance cmdlet. When using the Class parameter you cannot just enter the class name. You must use the class object returned from the Get-SCSMClass cmdlet. You can either do this directly in the command line by using parenthesis, or by saving the class to a variable. I suggest the latter when you will be using the same class multiple times in a script.

Get-SCSMClassInstance -Class (Get-SCSMClass -Name System.WorkItem.Incident) 

$class = Get-SCSMClass -Name System.WorkItem.Incident 
Get-SCSMClassInstance -Class $class

When you run this command it will return every incident in your Service Manager environment. You can narrow down your results by using filters. There are two ways that you can filter the results. You can use the Filter parameter, or you can use the where-object cmdlet. Which one you choose is really up to your preference and the requirements of your script. There are a few things to consider when choosing between Filter and Where-Object. When you use the Filter parameter it will only return results that make the filter. When using the Where-Object all objects are returned, but those matching the where-object are displayed. The filter parameter will typically run quicker and use less memory, but it is very finicky. It requires very specific formatting and is case sensitive with the properties. The where-clause is much more powerful than the filter. With the where-clause you can string together multiple criteria much easier, and work with sub properties and arrays. As I stated previously it is up to you which you choose to use. My personal preference is to use the where-object, unless I’m returning so many objects the filter causes a significant performance improvement. Below are examples using both methods to return incident ID IR3570.

Get-SCSMClassInstance -Class (Get-SCSMClass -Name System.WorkItem.Incident) | Where-Object {$_.ID -eq "IR3570"} 

Get-SCSMClassInstance -Class (Get-SCSMClass -Name System.WorkItem.Incident) -Filter "Id -eq IR3570"

*PowerShell Tip

You can use a simple question mark “?” in place of the Where-Object command. Be aware if you see a ? in future examples it is the same as typing Where-Object. This is known as an alias. When PowerShell was first created, they included aliases for well know commands. For example if you type “dir” into a PowerShell window, it will actually run the “Get-ChildItem” cmdlet. Over the years this has been expanded upon, and you can even create your own if you like.

Formatting Your Output

PowerShell allows you to control the output to the screen in multiple ways. The two we will work with here are Format-List and Format-Table, or FL and FT respectively. Format-List displays all results in a list form, with each property displayed on a separate line. Format-Table displays the properties across the top and the values below. Each of these can be run with or without the names of the properties you want to display.

Format-List

Format-Table

To find a list of all properties a cmdlet will return, you can use the Get-Member cmdlet. By adding a pipe and Get-Member to the end of a command, it will display all of the properties and methods associated with that command, but not their actual value.

When you run the command you’ll notice multiple member types. I will not go into detail here on what all the different member types are, but there are a few I would like to cover. You see there are multiple different type of properties (NoteProperty, Property, ScriptProperty). For now all you need to know is these properties are used to return values. For example, ID is a ScriptProperty and it returns the actual ID of the item. The other type we will be working with later on are the Methods. Methods allow you to examine, compare, and format many properties of a PowerShell object. We will cover methods more in later sections. For more information in the different MemberTypes refer to MSDN.

Saving Your Results

Often when you are using PowerShell you want to perform multiple things with the items you returned. To do this you can save your output into a variable. In the example below, I am writing the results to the variable $IR. Now, anytime I want to reference these results I just need to enter $IR.

$IR = Get-SCSMClassInstance -Class (Get-SCSMClass -Name System.WorkItem.Incident) | ?{$_.ID -eq "IR3570"}

Once you have your results loaded into the variable you can work with individual properties by using the variable name dot the property name.

$IR = Get-SCSMClassInstance -Class (Get-SCSMClass -Name System.WorkItem.Incident) | ?{$_.ID -eq "IR3570"} 
Write-Host "ID: " $IR.ID 
Write-Host "Title: " $IR.Title

Filtering Your Results

As you saw in the examples above I filtered the results on the ID of the Incident, using the logic ID –eq “IR3570”. So what if I want to return all incidents with a status of Active? I could try Status –eq “Active”. However, if I ran that I would receive zero results. This is because Active is a display name, and not the internal property name. A good rule of thumb to help you remember this is, if it is a list item (e.g. a dropdown on the form in console), then it will have an internal name and a display name. This is similar to what was covered earlier with classes. So in order to return Active incidents, you need to query off of the sub properties. Examples of these are shown below.

Get-SCSMClassInstance -Class (Get-SCSMClass -Name System.WorkItem.Incident) | ?{$_.Status.Name -eq "IncidentStatusEnum.Active"} | FT ID, Status 

Get-SCSMClassInstance -Class (Get-SCSMClass -Name System.WorkItem.Incident) | ?{$_.Status.DisplayName -eq "Active"} | FT ID, Status

The same logic here applies to all list items like category, urgency, impact, etc. We will cover ways to determine the name values of list items in a later post, but a quick way to find the internal name is to run the command against an item you know has the property set, and find the internal name in the output.

Working with Results

One of the best things you can learn to work with in PowerShell is the Foreach-Object cmdlet. It allows you to step through, and perform actions on each item individually. It can be run straight from the command line using a pipe or on its own. For simplicity we will be running it as a stand alone in the examples below.

Let’s go back to returning all Active incidents. I’m going to save the results to the variable $IR and I want to output the ID, Status, and Classification Category for each of these. If I simply did a FT and listed the properties out, it would return them, but it would return the internal names of the status and classification categories. To get the display name property we need to specify the sub property of display name. This can be done with the $IR.Status.DisplayName.

$IR = Get-SCSMClassInstance -Class (Get-SCSMClass -Name System.WorkItem.Incident) | ?{$_.Status.Name -eq "IncidentStatusEnum.Active"} 
Foreach($item in $IR) 
{
     Write-Host $item.ID "`t" $item.Classification.DisplayName "`t" $item.Status.DisplayName 
}

*PowerShell Tip

PowerShell ISE has a horrible habit of crashing the first time you try to enter information inside of the foreach brackets. It appears to be an issue with the auto-complete feature. To prevent this I always create the foreach with nothing inside the brackets, then execute the script. After doing this the auto-complete works, and ISE does not crash.

In this post you have seen how to determine the class of a work item and use that to return information about specific work items. The next few sections are going to cover creating and updating work items, and working with relationships. And also be sure to check the Overview Post for more content in this series.

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 workspace, 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.

# Service Manager Administrator Module 
import-module 'C:Program FilesMicrosoft System Center 2012 R2Service ManagerPowershellSystem.Center.Service.Manager.psd1' 

# Service Manager Data Warehouse Module 
import-module 'C:Program FilesMicrosoft System Center 2012 R2Service ManagerMicrosoft.EnterpriseManagement.Warehouse.Cmdlets.psd1'

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.

# Service Manager Administrator Module
$InstallationConfigKey = 'HKLM:SOFTWAREMicrosoftSystem Center2010Service ManagerSetup'
$AdminModule = (Get-ItemProperty -Path $InstallationConfigKey -Name InstallDirectory).InstallDirectory + "PowershellSystem.Center.Service.Manager.psd1"
Import-Module -Name $AdminModule
 
# Service Manager Data Warehouse Module
$InstallationConfigKey = 'HKLM:SOFTWAREMicrosoftSystem Center2010Service ManagerSetup'
$DWModule = (Get-ItemProperty -Path $InstallationConfigKey -Name InstallDirectory).InstallDirectory + "Microsoft.EnterpriseManagement.Warehouse.Cmdlets.psd1"
Import-Module -Name $DWModule

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.

if(@(get-module | where-object {$_.Name -eq 'System.Center.Service.Manager'}  ).count -eq 0)
{
    $InstallationConfigKey = 'HKLM:SOFTWAREMicrosoftSystem Center2010Service ManagerSetup'
    $InstallPath = (Get-ItemProperty -Path $InstallationConfigKey -Name InstallDirectory).InstallDirectory + "PowershellSystem.Center.Service.Manager.psd1"
    Import-Module -Name $InstallPath -Global
}

*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.

# add command to load Service Manager modules to profile
@'
$InstallationConfigKey = 'HKLM:SOFTWAREMicrosoftSystem Center2010Service ManagerSetup'
if(Test-Path $InstallationConfigKey)
{
$AdminModule = (Get-ItemProperty -Path $InstallationConfigKey -Name InstallDirectory).InstallDirectory + "PowershellSystem.Center.Service.Manager.psd1"
Import-Module -Name $AdminModule -Global
$DWModule = (Get-ItemProperty -Path $InstallationConfigKey -Name InstallDirectory).InstallDirectory + "Microsoft.EnterpriseManagement.Warehouse.Cmdlets.psd1"
Import-Module -Name $DWModule -Global
}
else
{
throw "ERROR: Could not locate Service Manager PowerShell module on cur"
}
'@ | out-file $profile -Append

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.

New-SCManagementGroupConnection -ComputerName "SCSM01"

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.

$ServerConfigKey = 'HKCU:SoftwareMicrosoftSystem Center2010Service ManagerConsoleUser Settings' 
$SvcMgmtSrv = (Get-ItemProperty -Path $ServerConfigKey).SDKServiceMachine 
New-SCManagementGroupConnection -ComputerName $SvcMgmtSrv

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

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.

Unless you’ve been living under a rock for the last few years, you know that PowerShell is the future for Microsoft. With products like Service Manager Automation and Azure Automation, a solid PowerShell foundation will be required for a lot of tasks.

When System Center 2012 was released the Service Manager PowerShell modules received a huge overhaul. There is almost nothing you can’t do using the provided Cmdlets. However, aside from the few examples on TechNet, there is not much documentation on working with the Service Manager Cmdlets. The purpose of this blog series will be to get you familiar with working with the Service Manager Cmdlets, and show you some of the great things you can accomplish using them.

All articles in their series are linked below. Be sure to read the overview below and check back often for new content and updates.

Series Overview

This series is not designed to be an introduction to PowerShell or Service Manager, just the Service Manager PowerShell modules. I assumes that you are familiar with Service Manager, and have a basic working knowledge of PowerShell. I will explain what the commands are doing, and I will provide links to additional resources where needed. This series will assume that you are familiar with running basic PowerShell commands and using PowerShell ISE. Some of the common PowerShell concepts we will use are variables, arrays, hash tables, foreach loops, and if else statements. Don’t worry if you are not experienced in all of these areas, you should still be able to follow along. I will explain what the commands are doing and provide links to additional information where needed.

I also recommend that you learn how to use the Get-Help and Get-Member cmdlets. They are not unique to Service Manager, and can be helpful with any PowerShell project.

Get-Help will return the help information for a Cmdlet.

Get-Member will list the properties and methods of a command or object.

Terminology – For those of you who are new to Service Manager, I suggest reviewing the Service Manager Glossary. One item that is not in the glossary that you will often see is Work Item. In Service Manager this can refer to Change Management, Incident Management, Problem Management, Release Management, Service Request fulfillment, and all Activity types. Basically everything under the Work Items workspace, in the console.

All code examples used in the series can also be found at https://gist.github.com/mdowst