Breaking All the Rules: Reactivating Closed Incidents

Breaking All the Rules: Reactivating Closed Incidents

  • Comments 5
  • Likes

OK – so ITIL/MOF best practices say that you shouldn’t reactivate or edit incidents which are in the Closed state and that you should create a new incident in that case.  I’m of the opinion that the intention of this is if the end user is re-raising the issue.  That makes sense to me (sort of).  So – in SCSM if you open an incident which is the Closed status you can’t edit it in any way and you can’t change the status back to Active or Resolved.  The whole form is disabled.  Interestingly, you can still change the extended property values and save those changes.

At any rate, there have been enough cases that customers have raised where it makes sense to allow editing a closed incident that I’m going to show you how to do that.  Here are just a couple of the cases:

1) You need to update the time spent on the incident, because somebody forgot to (or couldn’t) log it before the incident was closed.

2) The incident was flagged as ‘requires knowledge article’.  The knowledge manager has now provided a knowledge article and needs to unflag that incident so it doesn’t keep coming up in his “to do” list.

So – here is how you can enable reactivating closed incidents.

1) First download and install the SMLets cmdlets from http://smlets.codeplex.com

2) Import the attached MP.

You’ll see a new task in the task pane when you have an incident selected:

image

Just click that and it will change the status.  You may see a warning message like the one bloe that confirms that you want to run the script associated with importing the SMLets module:

image

You can get rid of this by opening Windows explorer to the .psm1 file mentioned in the dialog above, right click on it, and choose properties.  Then click the Unblock button.

You’ll need to refresh in order to be able to see the change in status.

Managment Pack download

Here’s a similar solution that Patrik built:

http://blogs.litware.se/?p=646

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Hi Travis,

    Just adding my 2-cents on this since we've already implemented a similar solution, but we added a validation to avoid errors while clicking that task on incidents that are not closed.

    This is the code that we're using (may not be a one liner, but it can be converted to that):

    $PROCNAME = "Reactivate Closed Incident"

    $ID = $Context/Property[Type='CustomSystem_WorkItem_Library!System.WorkItem']/Id$

    function Show-MessageBox ($msg) {

     [void] [System.Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms") | Out-Null

     [void] [Windows.Forms.MessageBox]::Show($msg, $PROCNAME, [Windows.Forms.MessageBoxButtons]::OK, [System.Windows.Forms.MessageBoxIcon]::Warning, [System.Windows.Forms.MessageBoxDefaultButton]::Button1, [System.Windows.Forms.MessageBoxOptions]::DefaultDesktopOnly) | Out-Null

    }

    Import-Module -Name smlets

    $IncidentClosed = Get-SCSMEnumeration IncidentStatusEnum.Closed$

    $IncidentStatus = Get-SCSMObject System.WorkItem.Incident$ |?{$_.ID -eq $ID} |%{$_.Status}

    if ($IncidentStatus -ne $IncidentClosed) {

     Show-MessageBox "Incident $ID cannot be re-opened because it is not closed."

    } else {

     Set-SCSMIncident -ID $ID -Status Active

    }

  • @German

    Good idea.  Thanks for sharing!

  • Hi Travis,

             Sort of not related to this post, but can't seem to find a better place to post the question. I was attending a presentation  held by Microsoft regarding Service Manager. They showed the funtionality where you can deploy SCCM packages via Portal. The question which sort of remained unanswered was, is it possible to control which users see published applications? Rephrasing the question, can groups be used to only allow users to see specific programs? And if yes, could you narrate that solution on the blog? Thanks in advance.....

  • @Zeglory

    I've been meaning to write an official blog post on this topic but haven't yet.  The approach is similar to what you would do in these blog posts:

    blogs.technet.com/.../how-to-target-knowledge-articles-at-different-groups-of-users.aspx

    blogs.technet.com/.../how-to-target-announcements-at-different-groups-of-users.aspx

    These are the rough steps that I worked out awhile back.  Should still work.

    Prerequisite step: Define your software processes and change request templates and assign them  in the Portal section of the Administration workspace as described in the product documentation.

    Now for the magic.

    1) First, remove Authenticated Users from the End User user role.  

    2) Create a group of all users using the Group wizard in SM.

    3) Create a group of the HR apps by using the Group wizard in SM and selecting the software processes and packages relevant to the HR apps.  You can also use dynamic groups so that it’s not so tedious to manage this one process or software package at a time.  

    Note: The display name for packages might be useless – it will be something like ‘CSV0001’, ‘CSV0002’, etc.  To figure out what is what run this query in the ServiceManager DB:

    Select * from MT_Microsoft$SystemCenter$ConfigurationManager$Package

    4) Create a group in SM of the Finance apps too.

    5) Create a security group in AD which represents the HR users and another one which represents the Finance users

    6) Create a user role based on the Change Initiator user role profile.  Grant no queues.  Grant the HR apps group and the All Users group.  Grant no views and no tasks and either all templates or just the ones that you have associated with the software processes above.  Put the HR users AD group in this user role.

    7) Create another user role based on the Incident Resolver user role profile.  Grant no queues.  Grant no groups.  Grant no views, no tasks, no templates.  Put the HR users AD group in this user role too.

    8) Repeat #13-14 for the Finance Users but select the Finance App group instead of HR App group.

    There are three very minor downsides to this approach:

    1) Users in these roles will be able to launch the main console.  They wont be able to do anything but what they could do in the portal though.

    2) Technically speaking, if users in these roles managed to figure out how to install the console, point it at the right server, and run a search for their incident, ….users in these roles will now be able to resolve incidents where they are the affected user.  But only those.  Probably not a big deal anyways.

    3) Because Authenticated Users is removed from the End User user role, you will need to make sure that all people that you want to have access to the portal are a member of these user roles as described above one way or another.

    Reminder:  Whenever you are testing user roles, make sure you log out of the OS and back in after changing a given user’s permission.  The updated permissions don’t take effect until the user logs out and back into Windows.

  • Travis, thank you for blogging on this feature.  Yes it is breaking all the rules from a process perspective, but Customers do ask for this and I hate telling them that they are breaking the process.  Since MOF/ITIL is a framework and IT has not matured their Problem Management processes to find out the root cause of recurring incidents, we need to provide this functionality.

    Thanks