none
Tasks on remote consoles

    Question

  • I am creating a few tasks that work well in the console on the primary management server.  But when users are on their local machines running the console the tasks error out.  The tasks I made are launching powershell so I assume this is because they do not have the cmdlets on there machines.  How do I get around this?  Do I need to push the smlets to all the analysts computers?

    - Get on the floor, do that dinosaur

    Tuesday, July 30, 2013 2:14 PM

Answers

  • Hi Pete

    You can use powershell remoting to do this.  You will need to enable PowerShell remoting on you management server using the Enable-PSRemoting cmdlet.  Then use the following command to allow your users (I am assuming that you have an AD group containing your users, and added to a SM role):

    Set-PSSessionConfiguration -Name Microsoft.PowerShell –showSecurityDescriptorUI

    This will allow you to configure permission in the UI.

    Then when you create your task use the invoke-command cmdlet to launch a PowerShell script.  Here is the command syntax I used:

    invoke-command -ComputerName <ManagementServerName> {"<PathToScriptOnManagementServer>\<ScriptName>.ps1" $Context/Property[Type='CustomSystem_WorkItem_Library!System.WorkItem']/Id$}

    You will need to package what you want to achieve up into a PowerShell script, but this works nicely, and you don't have to start distributing scripts to console users.

    HTH

    Cheers

    Shaun

    • Marked as answer by Pete Barbuto Monday, August 05, 2013 12:50 PM
    Tuesday, July 30, 2013 2:52 PM
  • First you need a Param ([string]$Id) in top of your ps1. Then when you call it from the task it goes like this:

    invoke-command -ComputerName <ManagementServerName> {"<PathToScriptOnManagementServer>\<ScriptName>.ps1" -Id $Context/Property[Type='CustomSystem_WorkItem_Library!System.WorkItem']/Id$} -Args $Id

    You should change code to -Filter instead of where, like this: 

    get-scsmclassinstance -Class (get-scsmclass -name "System.WorkItem.ServiceRequest") -Filter "Id -eq $Id"


    However, doing it like this changes the property directly on the instance, and not on the form. That means if your users try to update another property, they are met with an error of "another user or process have changed the item". They'l have  to refresh or reopen the workitem then. This can be avoided by doing it via the SDK, but a little more complicated though.



    Thursday, August 01, 2013 10:14 AM

All replies

  • Hi Pete

    You can use powershell remoting to do this.  You will need to enable PowerShell remoting on you management server using the Enable-PSRemoting cmdlet.  Then use the following command to allow your users (I am assuming that you have an AD group containing your users, and added to a SM role):

    Set-PSSessionConfiguration -Name Microsoft.PowerShell –showSecurityDescriptorUI

    This will allow you to configure permission in the UI.

    Then when you create your task use the invoke-command cmdlet to launch a PowerShell script.  Here is the command syntax I used:

    invoke-command -ComputerName <ManagementServerName> {"<PathToScriptOnManagementServer>\<ScriptName>.ps1" $Context/Property[Type='CustomSystem_WorkItem_Library!System.WorkItem']/Id$}

    You will need to package what you want to achieve up into a PowerShell script, but this works nicely, and you don't have to start distributing scripts to console users.

    HTH

    Cheers

    Shaun

    • Marked as answer by Pete Barbuto Monday, August 05, 2013 12:50 PM
    Tuesday, July 30, 2013 2:52 PM
  • Thanks for that, it does seem to work better.  Now I have to figure out where to put my variable in the script.  I have it in the Invoke-command like you do, but when I removed it from the ps1 it changed all of the work items...good thing it was a lab.  

    The purpose of my task is to change a service request to a custom status since there isnt a status changing task like incidents have.  Here is the code before removing it:

    (get-scsmclass -Computer scsm.petebarbuto.com -name "System.WorkItem.ServiceRequest" | get-scsmclassinstance) | where {$_.ID -eq '$Context/Property[Type='WorkItem!System.WorkItem']/Id$'} | %{ $_.Status = '3 Days To Closed' ; $_ } | update-scsmclassinstance
    Its basically Rob Fords status changing solution on his blog.  Do you know how I get the work item ID from the task into the script now?


    - Get on the floor, do that dinosaur

    Tuesday, July 30, 2013 5:34 PM
  • First you need a Param ([string]$Id) in top of your ps1. Then when you call it from the task it goes like this:

    invoke-command -ComputerName <ManagementServerName> {"<PathToScriptOnManagementServer>\<ScriptName>.ps1" -Id $Context/Property[Type='CustomSystem_WorkItem_Library!System.WorkItem']/Id$} -Args $Id

    You should change code to -Filter instead of where, like this: 

    get-scsmclassinstance -Class (get-scsmclass -name "System.WorkItem.ServiceRequest") -Filter "Id -eq $Id"


    However, doing it like this changes the property directly on the instance, and not on the form. That means if your users try to update another property, they are met with an error of "another user or process have changed the item". They'l have  to refresh or reopen the workitem then. This can be avoided by doing it via the SDK, but a little more complicated though.



    Thursday, August 01, 2013 10:14 AM
  • Hi, just another idea. i guess it will be easier to create a script to auto install the SM console and push out the SMlets at the same time.
    Thursday, August 01, 2013 10:38 AM
  • Morton, thanks for this, but if this method will cause errors then I am not going to implement it.  The console is already buggy enough without adding to that. I think that I have come to the conclusion that this is just not what tasks are meant to do and while there are ways to accomplish it, there are no good ways.  

    - Get on the floor, do that dinosaur

    Monday, August 05, 2013 12:44 PM