Huh, Change Request Status not updated … what now?

Sometimes you can run into trouble with Change Requests that do not update their status correctly. Normally, when you create a new Change Request you add at least one Activity to it. The whole Change Request as well as the first Activity switch their status to “In Progress”. Now, sometimes this is not really the case and you have to deal with uncompleted Change Requests – either in status new, submitted or pending – that will not update their status whatever you do. The GUI does not let you change the status of Change Requests in most situations. But here is a way you can do it to eliminate the “stale” Change Requests from your Service Manager Environment.

As you may have thought, we will use some Powershell stuff to solve this problem. First, make sure you have the smlets module copied to the System where you will do the work. The shown commands work directly on the Service Manager Management Server.

So fire up Powershell and import the smlet module:

import-module smlets


Next, store the classname for Change Requests in an array:

$class = get-scsmclass | where{$ -eq “system.workitem.changerequest”}


To display all Change Requests, use this command:

get-scsmobject -class $class


Now you have to define a filter to select exactly the Change Requests that you want to touch with the script later. Be very careful that you choose exactly those objects you want. Otherwise you will manipulate the wrong objects. Here are two examples:

get-scsmobject -class $class | where{$_.status -like “*bmit*”} (to choose all CR with the status “Submitted”)


get-scsmobject -class $class | where{$_.displayname -like “*database*”} (to choose all CR with the keyword “database” in the display name)


Now we are going to change the status. First step: Store the filtered Change Requests in an array. Second step: Change the status of all Change Requests in the array.

$CRtoChange = get-scsmobject -class $class | where{$_.status -like “*bmit*”}
$CRtoChange | set-scsmobject –property status
Enter the new status when prompted (cancelled, inprogress etc.)


Done, the Status has been changed. Use Powershell or the Service Manager Console to check it. Using the commands in this blogpost you can tidy up your environment and get rid of stale Change Request.

Happy scripting

About Marcel Zehner

Microsoft Azure MVP
This entry was posted in SCSM and tagged , , , , , , . Bookmark the permalink.

8 Responses to Huh, Change Request Status not updated … what now?

  1. Dennis says:

    Great way to use powershell. I have had this problem with change work items, so this is very usefull article 🙂

  2. Olivier says:

    Great ! I have the same problem with service request in SCSM. I use PowerShell for update my service request, then I update my review activities, then I update my runbook automation activies and my runbook Orchestrator do not start !
    Any help on how resolve this probleme without powershell ?


    • Marcel Zehner says:


      Hmm, hard to say. Do you have Errors/Warnings in the OpsMgr Event Log?


    • Oscar Aguilar says:

      Hi Olivier, Marcel
      The same thing happen to me, i opened a Service Request but this request never update the status from new to Submitted but this happend ramdonly, and i want to know if exist some script to make to Service Request.

      • Marcel Zehner says:


        Most of the time the reason for that is that (i) your environment has some issues and workflows are not running smoothly or (ii) your service request has no activities. If (i) is true, restart the Service Manager services on the workflow management server. If (ii) is true, make sure you have at least 1 activitiy in your request.


  3. KNCCO says:

    My organization also has the issue with SR tickets remaining perpetually in ‘New’ status (I found this thread while trying to figure out how to ‘fix’ them). What we found was that when the SCSM services hang/stop on the Management server, the workflows that move SR status from ‘New’ to the next status do not run (as expected). When the SCSM services are restarted, workflows start running again and status is updated. So far so good.

    But here’s the issue – if a user makes changes to the SR before the services have restarted, the SR remains permanently in ‘New’ status. Presumably making a change to the SR ticket makes it no longer fulfil the criteria for the workflow. In such cases, the only way we can get rid of the SR ticket is to manually change the status (same method as CR tickets in this article but with a different class name).

    Hope this info helps someone else.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s