Definitive Service Manager PowerShell: Part 5 – Creating Items

Definitive Service Manager PowerShell: Part 5

So far we’ve retrieved different types of things out of Service Manager and even changed a few of their properties entirely through PowerShell. Plus, we covered working with functions, loops, and the pipeline – which means at this point, you can work faster with items that already exist in Service Manager. Not only that, you can quickly shape and alter those items en masse. But what about creating new items in Service Manager from scratch? I thought you’d never ask. 

Create an Incident 

We have two ways of going about this. Let’s go over the quickest way exclusively available in SMLets – 

New-SCSMIncident –Title "Computer is burning" -Description "It seems to be on fire." -Impact "High" -Urgency "High" -Classification "Hardware" -Status "Active" -Source "Console" -SupportGroup "Facilities" –ComputerName "dev" 

While this makes things super easy, it may lead you to ask a question to the effect of “Then why can’t I find New-SCSMChangeRequest? Where is New-SCSMHardwareAsset?” And the truth is you won’t find these commands anywhere. For starters – if the commands worked that way, it means they would be near infinite in their existence given the number of classes that exist in SCSM (even more if you’re bringing in SCOM and SCCM classes).

So how do we create an Incident without this command? Or to be slightly more technical, how do we create an Incident Object from the Incident Class? We need something more generic than New-SCSMIncident. How about our next definitive command New-SCSMObject?

Function New-DevOpsIncident ($title, $description, $computername)
{
    $irClass = Get-SCSMClass -Name "System.WorkItem.Incident$" -computername $computername
    $incidentProperties = @{
        "ID" = "IR{0}";
        "Status" = "IncidentStatusEnum.Active$";
        "Title" = $title;
        "Description" = $description;
        "Classification" = $null;
        "Impact" = "System.WorkItem.TroubleTicket.ImpactEnum.High$";
        "Urgency" = "System.WorkItem.TroubleTicket.UrgencyEnum.High$";
        "Source" = "IncidentSourceEnum.Console$";
        "TierQueue" = "37efa6f4-b120-420b-b1e0-f15abed95d12"
        }
    New-SCSMObject -Class $irClass -PropertyHashtable $incidentProperties -computername $computername –PassThru
}

New-DevOpsIncident -title "Computer is burning" -description "It seems to be on fire." -computername "mgmtServer01"
New-DevOpsIncident -title "Fire" -description "That's no screensaver" -computername "mgmtServer01"

While going this route requires a few more lines than New-SCSMIncident, we’re still achieving the same end result of creating a custom Incident. We’re also combining a few topics from previous posts into our New-SCSMObject command. But they all should feel rather familiar at this point: 

• We’re wrapping the whole script into a function
  • Which serves the purpose of having a PowerShell template of sorts for a process we may execute frequently (e.g. creating an Incident for the DevOps team). It also means we could call the function rather easily in a foreach loop if we needed to
  • We’ve called the function twice, so we get 2 DevOps Incidents just to make sure you see the whole “write once, run many” in action
• We’re declaring the Class we want to work with  
• We’re working with simple text values and both flavors of lists – their dedicated name and behind the scenes unique identifier 
• We’re working with a PropertyHashtable just like we did in the post focused around Set-SCSMObject
• The made up management server of “mgmtserver01” I’ve turned into a variable – which makes this easy for sharing with others on my team regardless of the environment they are in

In fact, the only real changes here between Set-SCSMObject and New-SCSMObject is there are some values that are mandatory for creation of the particular class of object. If you were editing an item, the mandatory values are probably already set by virtue of using the Console, the Cireson SCSM Portal, or an Exchange Connector. As you can see that when it comes to creating an item the requirements are just a line or two more which is rather manageable once you functionalize your process!

Tip: Wondering what -passthru does? If you used New-SCSMObject without it, the new item would be created in Service Manager but it would not be shown on the command line. By adding -passthru not only can you see your recent creation but as your scripts grow you can leverage the recently created object within subsequent lines of the same PowerShell script. You don’t need it, but it is helpful more times than not.

Are the potentially ridiculously wide range of New-SCSMObject wrapped inside of a function use cases settling in? It is after all the means to create anything else in Service Manager…Computers, Printers, Users, Business Services, or…

Create a Problem

If Incidents are the one-off breaks in our environments, then Problems represent the underlying root-cause of those Incidents. Two very related concepts but still with their own processes and rules to follow. Let’s create a Problem using what we’ve learned about creating Incidents:

• We now have a High Priority Problem function
• Notice that Impact and Urgency Lists are actually identical behind the scenes between Incidents and Problems
• Still declaring our ID, passing in a Title, Description, and ComputerName

But what about…

Creating a Hardware Asset 

Now that we can create Incidents and Problems, let’s turn to something of the Asset nature. In this case, Hardware Assets.  

$environment = "dev"
$hwAssetClass = Get-SCSMClass -Name "Cireson.AssetManagement.HardwareAsset$" -computername $environment
$hwAssetID = (New-Guid).Guid
$hwAssetProperties = @{
     "ID" = $hwAssetID.ToString();
     "Name" = "New HW Asset Name";
     "DisplayName" = "New HW Asset Display Name which is probably the same as the name";
     "AssetTag" = "Unique Asset Tag goes here";
     }
$newHWAsset = New-SCSMObject -Class $hwAssetClass -PropertyHashtable $hwAssetProperties -computername $environment -PassThru 

What you’ve learned from creating Incidents and Problems is applicable here in the Hardware Asset world. We’re still: 

• using the same couple of commands 
• we’re following a near identical PowerShell pattern 
• we’re still creating wholly new items in Service Manager that didn’t previously exist

The variance that exists here is relatively small and no less something you should expect as you move between different Classes in SCSM. Since I’ve configured Cireson Asset Management to use GUIDs as the unique ID for Hardware Assets, I just use PowerShell’s New-Guid command to generate a new, unique, randomized Guid. But with PowerShell it should go without saying Incidents have different required properties than Hardware Assets. Hardware Assets have different required properties than Problems and so on, and so on. How do you know what these differences are? Experimenting! Service Manager and PowerShell error messages have your back as they will tell you directly on the command line if it couldn’t create a particular Object of a Class. 

But if you don’t want to guess, this is a fantastic opportunity to leverage a Service Manager user interface. What are required fields on the type of item you are creating? In this case, you can use the UI to give yourself hints when building with PowerShell.

Think you’ve got the hang of it? Time to put it to the test with… 

Powershell Homework Assignment #4 

• Create an Active Directory Printer or a Business Service:

• • Fill out as many properties as you can! 

• Create something of the Cireson Asset Management variety such as a:  

• • Catalog Item  
  • Subnet 
  • Location

• PowerShell Bonus:

• • Turn the Create Hardware Asset script above into a function but only use a single variable/parameter to set the Name and DisplayName properties
  • Create an Incident, but make it a Parent Incident

At this point we can get items out of Service Manager, we can change properties on them (text or list values), we can create Work Items or Configuration Items, and we can do it all remotely! Which means we have but a single topic left to address:

• How do you set the Primary Owner on a Hardware Asset? 
• How can you get all of the Incidents for a particular Department? 
• How many Incidents were related to that one Problem last week?
• How can you work with Parent/Child Incidents?
• How could you set the Impacted Service (i.e. a Server) in that New-DevOpsIncident function above?

In the next post it’s time to put everything you’ve learned up until now to the test. We’ll cover the centerpiece to Service Manager, the wider System Center ecosystem, reporting, PowerShell, your environment and the last of our definitive commands – working with and maintaining Relationships. Check out Definitive Service Manager PowerShell: Part 6!

Definitive Service Manager PowerShell Blog Series: Part 1 / Part 2 / Part 3 / Part 4