Kaseya Community

Execute Powershell "Return execution results to variable #global:psresults# and save in Docs tab"

This question has suggested answer(s)

Can anyone explain exactly how the feature "Return execution results to variable #global:psresults# and save in Docs tab" actually works?
Its seems to make a huge amount of assumptions about the output of a script.  An simply ticking the box does nothing. plus....

THE HELP FILE MENTIONS NOTHING OF THIS FEATURE!
Which drives me completely mental.

Thanks All.

All Replies
  • yeah I could never get it to work...or any of the inbult powershell commandlets.

    I have got this working by executing powershell.exe via other script method.

  • This step just executes powershell by either running a specified powershell script file, or an optional argument.

    If you want to view the results of the command, you can either check the Documents tab for the agent (viewed in Live Connect or the Agent Tab) and look for a new TXT file that contains the results.

    The results are also read to the variable #global:psresults#. You can do whatever you want with this, typically running an IF check on the variable or writing it to the Agent Procedure log.

    If it doesn't seem to do what you expect, check the agent procedure log for the particular agent you executed it on.

  • While on the topic. Check this out: community.kaseya.com/.../57217.aspx

    I run this in "old school mode" :)



    [edited by: Ronny Tunfjord at 3:31 AM (GMT -7) on 3-25-2011] misspell
  • @Ben, This is pretty much the expected behavior.  But the issues is that the tick box just simply doesn't do anything. And worse, the documentation doesn't even mention the tick box.  This is just unforgivable for a major software vendor.   And what if the powershell script doesn't have an output?  What happens then?  I expect nothing but I just cant know because its not in the documentation.

    @others.  I have been doing it the "old school" way for ages.  However, I though that it was nice that K added this feature.  Shame that its yet another cr@p feature that doesn't work and/or is undocumented

    Come on K. get it together.

  • If there is no output from the powershell command and you've checked the box to return results to a variable, your variable will simply contain no data and the text file will be empty or non-existent.

    If you are checking the box and it is not returning results when you try and leverage the variable, and you are sure the powershell script should be returning something to the shell as it executes, I'll take a look at how you are using it and if need be fix the custom step itself.

    Please get a ticket submitted and it will be assigned to me since I made the step.

    I will also send a note to our document writer to add a note in the help file about the check box.

  • Ben.  Thanks for the prompt response.

    I have done some testing and have the results.  Additionally, I have some notes:

    1) I created a two line agent procedure,

    - run powershell with "get-date" as the argument.  Ticked the box.

    - output #global:psresults# to proceedure log.

    Runs ok, no errors.

    No file is created with the output under the machines "documents" tab

    Proceedure log says "comment at then step 2"

    So doesn't work.

    2) When typing into the 'arguments' section the command is duplicated on the left side pane.  its hard to explain.  

    example: the only argument is "get-date".  in the  left pane the command says "execute powershell with params, get-date, get-date"

    It repeats itself.  Why is this?

    3) How does the conversion to a variable handle multi-line outputs?  Kaseya variables dont seem to be able to handle multi line outputs.  At least not for me.

    Ticket created.

  • I just went through the step and fixed the issue. I'll be sending you the updated step to apply on your server and we'll be hotfixing it out for everyone else soon.

    On the cosmetic issue with the left pane, it just attempts to summarize what your step is showing on the right. In this case the summary isn't properly using the check mark variable, a fairly minor issue I will fix that we'll ship with a hotfix.

    The conversion to multi-line output doesn't work well for writing to the agent procedure log, it's a limitation of the procedure engine right now we've got to get some additional work done on. Trust me, I want to see it but we have some core limitations we have to address. For now the best usage of the results variable is likely going to be to analyze it with an IF/ELSE check to check for some sort of custom condition.



    [edited by: Ben at 11:27 PM (GMT -7) on 3-28-2011] .
  • Amazing timing. Perhaps this is the same issue.  

    I'm trying to use the Execute Powershell step to issue a command. (Ultimately I want to be able to set the execution policy, but right I can't get any powershell commands to run).  When I run the script, there's an entry in the procedure log that says "Check for powershell failed."  My agent is running 2008 R2 Standard and I can run PS commands locally just fine.  

    Is this the same issue you just addressed or should I open a new ticket?

  • @Ben,
    Sorry, but this made no change whatsoever. 
    Downloaded and overwrote file and reapplied schema.  All ok.
    Re-run script from yesterday, same results.

    @Nathan
    This feature still has issues.  You can run it the 'old school' way.
    - To change the execution policy, run a shell command: powershell -command "& {Set-ExecutionPolicy unrestricted}"
    - To run a script, run a shell command: powershell c:\yourscript.ps1 >> c:\result.txt
    Just drop the ">> c:\result.txt" part if you don't care about the output.

    Good luck.

  • For my part....the Execute Powershell command has never worked since 6.1 in any shape or form.

    The other major problem I have noticed is scripts returning Success THEN ....but actually failing. This seems to be a bug with netsted IF's as the Fails dont always seem to get passed back up the chain.

  • Now that we can have nested IF statements it means we can check for conditions and write more descriptive log entries for successful and failure script events. I think it's a fair trade off, if you don't agree then you can always go back to using single if statements in your procedures and just daisy chain them together like in Kaseya 5.x Big Smile

    What many people don't get is that the Kaseya script language was originally written to do small very basic tasks and to execute other more complex scripts such as Batch or VBscripts. Over time due to user demand we have expected more complex functionality like you would get in most scripting languages which is why we got the nested IF statements and now the custom commands. As things get more complex the greater the chance that you will run into problems, so my advice is keep it simple if you can and know the limitations of what Kaseya can do and can't do.



    [edited by: HardKnoX at 7:35 PM (GMT -7) on 3-29-2011] typo
  • @HardKnoX

    Thank you for your input, your comments are both condescending and irrelevant.

  • @joshua.niland I will remember that for the next time you post a request for help Devil

  • I've tried a few Powershell scripts and after many hours frustration gave up as I couldn't get it to return any data regardless how simple the query was.  It's one of those things I just hope they'll fix in time.

    Have to agree with HardKnoX on this one.  The more features that are added in as procedures prompt more demand from what the system can actually do.  There are new users signing up for Kaseya daily so passing on some of his (rather vast) knowledge I don't see as either condescending or irrelevant.  I'm always glad to see posts from the likes of HardKnoX and other experienced users on here, like Ben and thirteentwenty.  We all know that Kaseya are not brilliant at passing on information so getting a hint and a tip from experienced Kaseya users is beneficial to everyone that uses the product.  

  • "Thank you for your input, your comments are both condescending and irrelevant."
    This comment is rather unfair.  Hardknox is really quite right.

    Kaseyas agent proceedures are NOT scripts.  This is likely why they changed the name from "scripts" when upgrading to 6.x.  but it is a tool that allows you to launch scripts on machines and return the results.  This is fine as other scripting languages (powershell, vbs, etc) will ALWAYS be FAR more powerfull than a Kaseya scripting language could ever be. It is what it is.

    My only issue is that what Kaseya does in Agent Proceedures, it should do well.  too often its buggy and has unpredictable results.  This thread is a good example.  I hate to think how many hours I have wasted trying to both decipher why a Proceeedure doesnt do what I want, and then trying to figure out a workaround to the bug I have found.

    Kaseya should not add any more functions (although the new ones are nice) but make sure that what it already does is BULLETPROOF!

    PS. As an extra note.  For what its worth I would like Kaseya to be able to handle and manipulate returned information better.  For example, return and store multi-line variables.  And maybe trim left, right or spaces.  Maybe character replacments and other string manipulations.  yes, I can do that in a client side scripts but it would be heaps easier if it were on the K side.