SM12 has a great feature for Service Level Management. I will not go into any details because this was already described here or here. With SM12 you are very flexible to deal with different service levels, metrics and also time zones. In the background things happen different from SM10 as now an object of type “Service Level Instance Time Information” is created for every new SLO that applies to an Incident. This object is then referenced to the incident. One Incident can have multiple SLOs applied, for instance one because an Incident is a Priority 5 Incident, and another one because the affected User is a VIP User. The downside of this approach is that handling the “target end date” of incidents is a bit more complex because you always have to use the relationships and then find out what the effective target end time is. This blog post shows how this can be made a little bit easier.
I wanted to have a way to easily get the target end date of every incident out of the database as easy as possible. Therefore I created a runbook that gets the most restrictive SLO of an Incident and writes this to a text property of the incident. Then you can simply read this property and have the needed information without always having to deal with relationships. I solved this with a simple Orchestrator runbook that looks like this.
The first activity monitors if new objects of type “Service Level Instance Target Information” is created. If this is the case, the runbook gets triggered.
The scripts looks like this.
$SMDefaultComputer = “scsm01.itnetx.ch”
$SLAID = ID from “Monitor Object” (published data)
$incident = @()
$incidentobj = @()
import-module smlets –force
Get classes, relationships and enumerations
$class_SLATimeInfo = get-scsmclass -name System.SLA.Instance.TimeInformation$
$class_Inc = get-scsmclass -name system.workitem.incident$
$rel = get-scsmrelationshipclass -name System.WorkItemHasSLAInstanceInformation$
$status_SLAActiveID = (get-scsmenumeration -name SLAInstance.Status.Active$).id
Get SL instance time information objects
$SLATimeInfos = get-scsmobject -class $class_slatimeinfo -filter “id = $SLAID”
Get all Incidents related to the SL instance time object fro the last step
foreach($SLATimeInfo in $SLATimeinfos)
{
$incident = (get-scsmrelationshipobject –bytarget $SLATimeInfo).sourceobject
$incidentobj += $incident.adaptemo()
}
Delete duplicate Incident objects from the array
$incidentobj = $incidentobj | select –unique
Get all SL instance time information objects for incidents and select earliest target end date, then write back to text field “Target Resolution Time” (as this field is not used anymore with the new SLO SM12 feature)
foreach($inc in $incidentobj)
{
$SLATimes = $inc | get-scsmrelatedobject | where{$_.classname -eq $class_slatimeinfo} | foreach{$_.targetenddate}
$TargetTime = $SLATimes | sort | select -first 1
$inc | Set-SCSMObject -Property targetresolutiontime -value $targettime
}
Feel free to optimize this a little bit as this was from a quick and dirty approach 
Now check the runbook in and start it. After that create a new incident and make sure one or multiple SLOs target this incident. It takes some time until the SM workflow engine applies the SLOs (creates those objects).
Then after while the runbook should be triggered and the earliest target end date should appear in the target resolution time field.
With this field populated you are now more flexible to work with the target resolution time, e.g. to display that information in the regular incident views or when somehow extracting this information out of the database.
Have fun
Marcel
marcelzehner.ch 
Hi
Nice solution since MS did’nt find it important to be able to sort on “target end date” in a view. If a customer don’t have an Orchestrator server – is it then possible to modify the script to run as a scheduled PS every 5 min ? I’m not a scripting expert ….
Hey
Never tried it without Orchestrator. But you could build a custom workflow that gets triggered the same way as the Orchestrator runbook. Then just execute the script. Give it a try!
regards
Marcel
Any thougts on how to make SLO’s use pause or hold functionality. A lot of clients need to be able to put incidents on hold waiting for client responce, input etc. It’s an interestign argument of this being allowed or noy but regardless alot want it and SLO is not able to accomodate for it.
Hey
There’s no supported way to do this today …
regards
Marcel
Any unsupported way? Have read material where all the plumbing seems to be there but just not quite finished. Even a blog where it has been done, like http://blog.scsmsolutions.com/2012/08/pause-sla-in-scsm-2012-yes-you-can/
but not quite finished or published.
Mat
Hey
True. But we are not allowed to talk about that 🙂
regards
Marcel
Hi Marcel,
I created the run book however cannot get it display in scsm 2012 console under Library/Runbooks. It shows on the scorch web console.
Many Thanks
Hey
This is a “Monitor” Runbook that checks for situations and triggers if needed. These kind of runbooks are not synchronized to SCSM because you cannot use those as part of the Business Process. Anyway, this is not needed. Only Runbooks that start with an “Initialize Data” activity are synchronized.
Cheers
Marcel
Hey Marcel,
i wanna use your solution. Its a bit crazy that MS didn’t thought about that.
but i get a failure in the Orchestrator, the Connector between scsm 2012 and Orchestrator.
“The term ‘get-scsmclass’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. Can you help me resolving that?
Cheers
Fabian
Hey
Did you import the smlets PoSh Module first?
Cheers
Marcel
Hi Marcel,
I am getting the same error “‘get-scsmclass’ is not recognized ” when I test the runbook on my runbook server. “import-module smlets –force” is included in the PoSh code as you described.
Hey
I bet that SCORCH does not find the module or something needed by the module. Keep in mind that SCORCH is a 32bit app and searches for the module in a different place. Also make sure that the Execution Policy is set not only in the regular 64bit Powershell, but also in the 32bit one. the last hurdle is the path where the SCSM binaries are stored. Check out Anton’s post for more details –> http://blog.scsmsolutions.com/2012/09/configure-smlets-beta-4-for-working-with-orchestrator/.
Cheers
Marcel
Hey Marcel,
sorry for reply so late. I was not in my office till now. I could solve that issue. But there comes an other failure and after a bit searching ive seen that i have mistakenly chose the type = “Service Level Insance TIME INFORMATION”. The reason why i chose that is because i have no “Service Level Instance Target Information”.. i have really no idea why. i hope you can help by.
greetings,
Fabian
Hi, I tested this quite extensivley a week or so ago and found it worked perfectly well. However, running into a strange issue now. The runbook says it succeeds but the field is not populated. I ran the script outside of the runbook to see if I get any errors and I get the below:
Set-SCSMObject : String was not recognised as a valid DateTime
Further down I see:
CategoryInfo: ObjecNotFound (12/19/2012 14:01:28:String)
I’m wondering if it’s a conversion between American and UK date formats somewhere?
Any help would be greatly appreciated!
Thanks,
Kris
Hey Kris
Strange, I have not seen this before. I would go through the script step by step and check all the objects that are created/used. I could imagine that it’s a date/string problem. But in that case I wonder why it worked before when you did the tests 🙂
Cheers
Marcel
Hi Marcel,
I think it worked when I ran the tests because the dates of the SLAs could all have been valid dates reading them either UK format or US format. For example last week the date of resolution would have been 4th December 2012. Reading as either 04/12/2012 or 12/04/2012 but both valid dates. Now the resoution times have gone over 12 I get the error of invalid date which I’m guessing is because it’s reading them as the 13th month instead of the 13th day.
I conducted a further test which was to set the regional settings on the Orchestrator server to be US and the script ran fine when I run it manually or when I use the step through tests. It still doesn’t work though when It’s running automatically!
Thanks,
Kris
I have got the same problem here, i am wondering if you solved yours!
Hi Marcel,
ok please ignore my previous question about “Service Level Instance Time Information” i’ve seen the screenshort and recognised that everything was correct. BUT i get an exception anyways. When i use the runbook tester the monitor object works well. But then the Run .Net Script caused an Error: “The term ‘SLAInstanceTimeInformation_88c1b335-6f8e-47f3-9fc8-c8b7b0d40938’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.”
hope you can help me. and thank you very much for helping me!!
Hey
Hmmm, it seems you have a problem with the syntax. Did you re-check that?
Cheers
Marcel
Yes, 3 persons viewed the code but no one could discern any differences. Maybe its maybe something in the first part?
this is my syntax:
$SMDefaultComputer = “SMServerName.Domain”
$SLAID = {ID from “Monitor Object”}
$incident = @()
$incidentobj = @()
import-module smlets –force
do you have any idea from which part the error could come?
This is the Error Text: The term ‘SLAInstanceTimeInformation_611d9b86-9b5b-4de8-ba34-55c0eb56b9e8’
I wanna post my Code, if its to much please feel free and delete this one. I have a copy and post a spam-free version 😉
$SMDefaultComputer = “hds1090.hd.hud”
$SLAID = \`d.T.~Ed/{A5AE0421-F979-4917-AE6B-15A07440AC3D}.Id\`d.T.~Ed/
$incident = @()
$incidentobj = @()
import-module smlets –force
$class_SLATimeInfo = get-scsmclass -name System.SLA.Instance.TimeInformation$
$class_Inc = get-scsmclass -name system.workitem.incident$
$rel = get-scsmrelationshipclass -name System.WorkItemHasSLAInstanceInformation$
$status_SLAActiveID = (get-scsmenumeration -name SLAInstance.Status.Active$).id
$SLATimeInfos = get-scsmobject -class $class_slatimeinfo -filter “id = $SLAID”
foreach($SLATimeInfo in $SLATimeinfos)
{
$incident = (get-scsmrelationshipobject –bytarget $SLATimeInfo).sourceobject
$incidentobj += $incident.adaptemo()
}
$incidentobj = $incidentobj | select –unique
foreach($inc in $incidentobj)
{
$SLATimes = $inc | get-scsmrelatedobject | where{$_.classname -eq $class_slatimeinfo} | foreach{$_.targetenddate}
$TargetTime = $SLATimes | sort | select -first 1
$inc | Set-SCSMObject -Property targetresolutiontime -value $targettime
}
Thank you so much!
Hey
Add quotation marks and try again:
$SLAID = “{ID from “Monitor Object”}”
Cheers
Marcel
aah, thank you! It works now… i get some errors “Cannot bind argument to parameter ‘ByTarget’ because it is null.” i think its becaue we have some tickets without SLO.
But i have the strange issue, and I dont know why. I can’t display the target resolution time any more OR i only use the false “detail”.
Target End Date is correct isn’t it? If I use it I the top label did not show “target resolution time or target end date” but it shows in german “geplantes enddatum” without any content.
The button “incident settings ->do not show[..]” is checked
Pingback: SLA in SCSM 2012. Part 2. How it’s works | SCSM: all for administration and development
Stuipd question where do I get the {ID from Monitor Object}?
Hey
This is data that gets published by another activity, in this case from the activity “Monitor Object” (published data is one of the main concepts of SCORCH). Right click the field that you want to fill in published data, right click and select “published data”.
Cheers
Marcel
Thanks Marcel, I’m now also seeing the Cannot bind agrument to parameter ‘ByTarget’ beacuse it is numm? Any thoughts? I had our Powershell guy look at it but did not have any ideas?
I’m lost the runbook keeps throwing up this error “The module to process ‘SMLets.psm1’, listed in field ‘ModuleToProcess’ of module manifest ‘C:\Windows\system32\WindowsPowerShell\v1.0\Modules\smlets\smlets.psd1’ was not processed because no valid module was found in any module director” I am able to manually open Powershell and import the module but when it run in SCORCH it gives this error…
Hey
Not sure, but did you keep in mind the SCORCH 32bit problem regarding powershell?
Cheers
Marcel
Yeah, I ran the set-execution policy for both x86 and x64 powershell. it’s happening in my Training Lab and production.
Hmmm, in what folder did you place the smlets module folder?
I am getting this same error. I have the smlets listed under these locations on Orch and Service Manager:
“C:\Windows\SysWOW64\WindowsPowerShell\v1.0\Modules\”
“C:\Windows\System32\WindowsPowerShell\v1.0\Modules\SMLets\”
“C:\Program Files\Common Files\SMLets\”
Any help would be appreciated.
Hey
It seems you have some troubles getting the smlets module to load. This could be caused by the fact that SCORCH is a 32Bit app running on a 64Bit OS. Check out Antons blog post for details on how to fix that –> http://blog.scsmsolutions.com/2012/09/configure-smlets-beta-4-for-working-with-orchestrator/
Cheers
Marcel
I am getting the following error, did i miss anything:
Cannot bind argument to parameter ‘ByTarget’ because it is null.
i get the same error………..
the strange Thing is , in runbook tester it is wokring fine. But when i start the runbook i get this error message
Hi Marcel,
one (hope not so stupid) question..;-)
Must the script seperated into different Powershell script activites or must the complete code used in only one activity?
THX
Markus
Hi Marcel,
I have put the complete script into one Script activty.
But I get this Error message “Method invocation failed because [Microsoft.EnterpriseManagement.Common.EnterpriseManagementObject] doesn’t contain a method named ‘adaptemo’.”
Any idea what this can be?
many thanks
markus
found it..the porblem was the modification of the smlets.psm1
Hi Marcel,
Any Idea how we can fix this “Cannot bind argument to parameter ‘ByTarget’ because it is null.” Problem? Absolutly no idea how i can fix this….
Thanks
Hey
Hard to say. Try to find out in a step-by-step approach why the variable that you use for the “ByTarget” parameter is empty.
Cheers
Marcel
Hi Marcel,
The Problem occurs only when the runbook is running. When I test it in runbook tester ist working fine. Where is there the diffenerence? Could it be a Timing Problem on the Trigger?
THX
ME
Hi Marcel,
I finally managed to run the runbook without any error. However when I go to Service Manager Console I realized that Target Resolution Time values at the Views are still empty even though the SLA information changes on the Incidents.
I got the following error:
Unable to load DLL ‘mscorwks.dll’: The filename or extension is too long. (Exception from HRESULT: 0x800700CE)
Hi Marcel,
I have followed all your instructions and also followed all the instructions in Antons blog. I can open an elevated windows powershell (x86) and x64 and copy the script in there and it works until it gets to -bytarget. When I run it in Runbook I am still getting “The term ‘get-scsmclass’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.”
Any help would be appreciated.
Thanks
Sarah
I resolved this by entering the full path to the module:
import-module “C:\Program Files\Common Files\SMLets\SMLets.psd1” –force
Hey Sarah
Thanks for sharing!
Cheers
Marcel
I have come across another issue. We need to use the last target end date rather than the first date but I am no Powershell coder. I’d be really grateful if you could point me in the right direction please. I had assumed that it would be a matter of changing first to last but it didn’t work and I’d be grateful for any help as this would make it so much easier to see our target resolution dates :
foreach($inc in $incidentobj)
{
$SLATimes = $inc | get-scsmrelatedobject | where{$_.classname -eq $class_slatimeinfo} | foreach{$_.targetenddate}
$TargetTime = $SLATimes | sort | select -last 1
$inc | Set-SCSMObject -Property targetresolutiontime -value $targettime
}
Thanks
Sarah
OK I’m going into begging mode now …. can someone please please help me. I’m on the verge, I think, of getting it to work how we need it but I’m stuck on the last bit and don’t know how to fix it.
We have multiple SLAs and though the code here gets the most restrictive SLO of an Incident, I need the most recently added SLO. So I need it to pull out the SLO with Cancelled eq no and sort the results by the Last Modified date. I’d be so grateful if someone could help me because it would make this system so much easier to use if we could sort the target resolution time.
Many thanks
Sarah
Pingback: SCSM 2012. Data Warehouse. Reports. Как получить инциденты закрытые в рамках SLA | Aleksandr's Shramko blog
Pingback: SCSM 2012. Data Warehouse. Reports. Как получить инциденты закрытые в рамках SLA | Aleksandr's Shramko blog