locked
Powersehll workflow only working after restarting services RRS feed

  • Question

  • I have the following powershell script for closing 'Completed' changes which works fine when run from the powershell cmd line.

    --------------------------------------------

    import-module smlets

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

    $CRtoChange = get-scsmobject -class $class | where{$_.status -like "*Completed*"}

    $CRtoChange | set-scsmobject –Property status -Value Closed

    -----------------------------------------------

    However if I put this script into a workflow in the authoring console, deploy the dll and xml etc. The workflow runs successfully but the 'Completed' changes never close.

    The strange thing is that if I restart the 'System Center Management' service on the SM server the workflow runs and closes any changes in a 'Completed' state the first time it runs after the restart. All subsequent runs do not.

    If I look in the DB I can see the following error when the workflow runs:

    C:\Windows\system32\WindowsPowerShell\v1.0\Modules\ActiveDirectory\ActiveDirectory.Types.ps1xml : File skipped because it was already present from "Microsoft.PowerShell".

    It is as if because the module is already loaded the workflow will not run and if you restart the service it unloads the module for the one run. The confusing thing is that I have another workflow for closing incidents which fundamentally does the same thing and works fine.

    Can anybody see what is wrong here?

    Thanks

    Mark


    Mark | http://syscen.blogspot.com/
    Wednesday, March 23, 2011 12:33 PM

All replies

  • This error has popped up a couple times for other people, too (including myself). In my case it was because I was using the wrong execution policy. I set it to RemoteSigned and the error went away. (Unrestricted worked as well)

    Other folks have had success in explicitely unloading the modules after the script runs..if you have a startup script that's loading modules, you could try loading and unloading them explicitely in your script instead.

    Thursday, March 24, 2011 1:38 PM
  • Hi

    The Powershell policy is set to 'Unrestricted' and I have tried unloading and loading the module. Although not sure I am doing this correctly so if somebody could post the cmds that would be appreciated.

     I have done a little further testing and my workflow is set to trigger every five minutes. This is just while i'm testing. It seems that the workflow does 'close' the changes intermittently. For instance if I mark a change 'Completed' it will close say an hour later even though the workflow is running every 5 mins.

    Thanks

    Mark


    Mark | http://syscen.blogspot.com/
    Friday, March 25, 2011 8:32 AM
  • Hi Mark -

    Do you have remove-module smlets at the end of your script?

    You should also try checking the JobStatus table to see what's going on:

    http://blogs.technet.com/b/servicemanager/archive/2009/12/21/troubleshooting-workflows-in-service-manager.aspx

    Pete

    Wednesday, March 30, 2011 2:27 PM
  • I had this same issue. Try adding remove-module -name SMLets -force to the end of your script. Also make sure that if you have any other Powershell workflows running that they have this line as well. For me the problem was that there was another workflow that had been added previously added that did not have this line, so the workflow I created would error.

    I hope this helps,

    -Lee

    Thursday, May 12, 2011 11:54 PM
  • To be honest, my guess is rather that this a bug with the SMlets module. Why?

    Try this a standard PowerShell session:

    Import-Module SMlets /hit enter
    $error / hit enter
    Remove-Module SMlets / hit enter
    $error / hit enter

    The $error variable is a standard 'per PowerShell PID session local' variable where all error messages are captured (even if they won't appear in the console shell at all)

    So far, you shouldn't see any content in the $error variable right?

    Now just try to re-import the SMlets module again in the same PowerShell session you've used before and display then again the content of the $error variable.

    Dang, now you should see an error message which looks familiar?! In the PowerShell console shell you won't see that error message however. I guess the module authors have redirected it to [void] or have the erroraction switch per default set to silentlycontinud (but that's just a guess).Or it could also be related to this bug http://connect.microsoft.com/PowerShell/feedback/details/587808/update-formatdata-doesnt-check-if-file-is-already-loaded-and-gets-error#details? I've tried that with several other modules and pssnapinsnd couldn't reproduce it, only with the SMlets I was getting this behaviour.

    Now I assume the SCSM Workflow engine causes workflows to stop when such an error message is logged in the $error variable and the 'Continue on error' option is set to False. I've implemented a Send-Mail part in my workflows and based on whether an error was logged in the $error variable or not it sends a 'Workflow succeeded' or 'Workflow failed' (I've specified to continue on error in my workflow, therefore I'm getting the mails everytime). Now the funny thing I've noticed is that every 10th execution succeeds and I receive a 'Workflow succeeded' email. The rest fails and I receive 'Workflow failed'...

    Is it possible that for whatever reason the workflow engine doesn't close the PS sessions directly after workflow execution and only after a certain execution count? This could explain the issue (atleast I think so).

    I'll submit a bug report in the codeplex forum for this and will see what the authors will reply.

    Cheers

    Alex

    Wednesday, August 15, 2012 12:03 PM
  • This should be fixed for loading SMLets if you use the Beta 3 version.

    To fix for the SM modules that are provided out of the box please see this blog post:

    http://blogs.technet.com/b/servicemanager/archive/2013/01/10/resolving-the-error-file-skipped-because-it-was-already-present-from-microsoft-powershell.aspx

    Looks like this bug has been marked as Fixed on the PowerShell Connect site so hopefully this is resolved in WS 2012(?). 


    Travis Wright, Principal Program Manager, Microsoft

    Thursday, January 10, 2013 10:27 PM