Trigger Alert - Executing External program does not work in executing PowerShell script ?

This is how I use that action. Here is an example for a script action I use to delete nodes.

In the External program area you will need this info. In this case I'm using the variable for the Caption of the node but you can adjust to your on needs. Also make sure the path to the powershell scripts on your Orion server is specified as shown. 

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -Command "C:\scripts\MyPowershellScript.ps1 '${N=SwisEntity;M=Caption}'"

Hi, 

I have provided the Delete node Powershell script executed via NodeID and I have given the path as C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -Command "C:\scripts\Test.ps1 '${N=SwisEntity;M=NodeID}'"  but the trigger action wouldn't execute even though the alert was triggered for my condition.

Any Suggestion where I might need to look to Troubleshoot?

KMSigma.SWI : Need your help!!

The wording for your script looks good for me. Some things to check

Do you have the Solarwinds SDK installed on the server itself? Powershell on the server needs to have the plug in available.

Is the path and filename to your script correct

Does the user set up in the alert action have node management rights and does it match the user in the script?

Below is an example you can try. 

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -Command "C:\scripts\deletescript.ps1 '${N=SwisEntity;M=Caption}'"

#You need to have ORION.SDK installed on your server or this will not run
#
Add-PSSnapin SwisSnapin
#Put your Orion Server, User, and Password here, needs to match the one you set up in the alert action
#Alternately you can use -Trusted and use an AD account that matches the one you set up in the alert action
#$swis = Connect-Swis -host YOURORIONSERVER -trusted
$swis = Connect-Swis -host YOURORIONSERVER -username ORIONUSER -password ORIONUSERPASSWORD
$server = $args.get(0);
$nodeUri = Get-SwisData $swis "SELECT Uri FROM Orion.Nodes WHERE caption LIKE '$server'"
Remove-SwisObject $swis $nodeUri

I don't have Orion SDK installed on the Server but I have SwisPowershell module installed in the Server.

I was able to Unmanage the node through Powershell script but Delete node wouldn't work.

As the Unmanage Script works fine , I assume the User Setup, Path are working fine. I tried to run the script manually for Delete node and it works. Only when I try to execute via external Program , it wouldn't perform the trigger action.

In the Active Alert Details, I can see Trigger Action for Unmanage PowerShell executed successfully, but Trigger action for Delete node isn't triggered at all.

Not sure what I am missing.

Your execution policy might be blocking it from running. Not super normal, but might be a thing as I've seen it in a few scenarios.

Also I don't think your double-quotes and parameters are in the right locations.  You said:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -Command "C:\scripts\Test.ps1 '${N=SwisEntity;M=NodeID}'"

And I'm pretty sure it should be:

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -File "C:\scripts\Test.ps1" "${N=SwisEntity;M=NodeID}'"

The Command parameter assumes you are sending a script block and not a file to be read and executed.

Help for the PowerShell executable below:

C:\Scripts> powershell.exe /?

PowerShell[.exe] [-PSConsoleFile <file> | -Version <version>]
    [-NoLogo] [-NoExit] [-Sta] [-Mta] [-NoProfile] [-NonInteractive]
    [-InputFormat {Text | XML}] [-OutputFormat {Text | XML}]
    [-WindowStyle <style>] [-EncodedCommand <Base64EncodedCommand>]
    [-ConfigurationName <string>]
    [-File <filePath> <args>] [-ExecutionPolicy <ExecutionPolicy>]
    [-Command { - | <script-block> [-args <arg-array>]
                  | <string> [<CommandParameters>] } ]

PowerShell[.exe] -Help | -? | /?

-PSConsoleFile
    Loads the specified Windows PowerShell console file. To create a console
    file, use Export-Console in Windows PowerShell.

-Version
    Starts the specified version of Windows PowerShell.
    Enter a version number with the parameter, such as "-version 2.0".

-NoLogo
    Hides the copyright banner at startup.

-NoExit
    Does not exit after running startup commands.

-Sta
    Starts the shell using a single-threaded apartment.
    Single-threaded apartment (STA) is the default.

-Mta
    Start the shell using a multithreaded apartment.

-NoProfile
    Does not load the Windows PowerShell profile.

-NonInteractive
    Does not present an interactive prompt to the user.

-InputFormat
    Describes the format of data sent to Windows PowerShell. Valid values are
    "Text" (text strings) or "XML" (serialized CLIXML format).

-OutputFormat
    Determines how output from Windows PowerShell is formatted. Valid values
    are "Text" (text strings) or "XML" (serialized CLIXML format).

-WindowStyle
    Sets the window style to Normal, Minimized, Maximized or Hidden.

-EncodedCommand
    Accepts a base-64-encoded string version of a command. Use this parameter
    to submit commands to Windows PowerShell that require complex quotation
    marks or curly braces.

-ConfigurationName
    Specifies a configuration endpoint in which Windows PowerShell is run.
    This can be any endpoint registered on the local machine including the
    default Windows PowerShell remoting endpoints or a custom endpoint having
    specific user role capabilities.

-File
    Runs the specified script in the local scope ("dot-sourced"), so that the
    functions and variables that the script creates are available in the
    current session. Enter the script file path and any parameters.
    File must be the last parameter in the command, because all characters
    typed after the File parameter name are interpreted
    as the script file path followed by the script parameters.

-ExecutionPolicy
    Sets the default execution policy for the current session and saves it
    in the $env:PSExecutionPolicyPreference environment variable.
    This parameter does not change the Windows PowerShell execution policy
    that is set in the registry.

-Command
    Executes the specified commands (and any parameters) as though they were
    typed at the Windows PowerShell command prompt, and then exits, unless
    NoExit is specified. The value of Command can be "-", a string. or a
    script block.

    If the value of Command is "-", the command text is read from standard
    input.

    If the value of Command is a script block, the script block must be enclosed
    in braces ({}). You can specify a script block only when running PowerShell.exe
    in Windows PowerShell. The results of the script block are returned to the
    parent shell as deserialized XML objects, not live objects.

    If the value of Command is a string, Command must be the last parameter
    in the command , because any characters typed after the command are
    interpreted as the command arguments.

    To write a string that runs a Windows PowerShell command, use the format:
        "& {<command>}"
    where the quotation marks indicate a string and the invoke operator (&)
    causes the command to be executed.

-Help, -?, /?
    Shows this message. If you are typing a PowerShell.exe command in Windows
    PowerShell, prepend the command parameters with a hyphen (-), not a forward
    slash (/). You can use either a hyphen or forward slash in Cmd.exe.

EXAMPLES
    PowerShell -PSConsoleFile SqlSnapIn.Psc1
    PowerShell -version 2.0 -NoLogo -InputFormat text -OutputFormat XML
    PowerShell -ConfigurationName AdminRoles
    PowerShell -Command {Get-EventLog -LogName security}
    PowerShell -Command "& {Get-EventLog -LogName security}"

    # To use the -EncodedCommand parameter:
    $command = 'dir "c:\program files" '
    $bytes = [System.Text.Encoding]::Unicode.GetBytes($command)
    $encodedCommand = [Convert]::ToBase64String($bytes)
    powershell.exe -encodedCommand $encodedCommand

Can you post the script you are trying to run?

I'm trying to execute alert for node down more than 30 days as explained by KMSigma in The Curious Case of the "Dead" Nodes - Product Blog - Resources - THWACK, Unmanage the node as Escalation 1. Then wait for xx days Inform the team via email and Delete the node as Escalation2.

Unmanage node works fine, but Delete node wouldn't work. I understand there may be error with the PowerShell path/Script/User/Permission. But I noticed today, that the email action also wouldn't trigger.

The alert was not Acknowledged , so it is supposed to fire the 2nd Escalation of Email as well the delete PowerShell script. But both of the actions didn't fire.

If Orion SDK is required mandatorily, then Unmanage PowerShell script shouldn't work, but Unmanage works fine when Delete doesn't.

Start-Transcript Filepath
if ( -not $args[0] ) {
   Write-Error -Message "You must provide the Node ID as a parameter to the script"
}
else {
   Import-Module -Name SwisPowerShell
   $NodeID = $args[0]
   $SwisHostname = "FQDN"
   $SwisUsername = "admin"
   $SwisPassword = "password"
   $SwisConnection = Connect-Swis -Hostname $SwisHostname -UserName $SwisUsername -Password $SwisPassword
   $Uri = Get-SwisData -SwisConnection $SwisConnection -Query "SELECT Uri FROM Orion.Nodes WHERE NodeID = $NodeID"
   Remove-SwisObject -SwisConnection $SwisConnection -Uri $Uri
}
Stop-Transcript

I think the problem here is in the way that "unmanage" works.  It stops polling AND alerting.  After the node has been flipped to unmanaged, it won't trigger any more alerts and therefore no more actions and or escalations.

The thought process was that you would manually run the second portion as a scheduled task since the alert engine can't "do" things against elements that are muted or unmanaged.

I'd probably have an automated scheduled task that runs once daily and queries for Unmanaged Nodes and the date of that change.  If the difference is 14 (or whatever) days from today, then delete the node.

I think the problem here is in the way that "unmanage" works.  It stops polling AND alerting.  After the node has been flipped to unmanaged, it won't trigger any more alerts and therefore no more actions and or escalations.

The thought process was that you would manually run the second portion as a scheduled task since the alert engine can't "do" things against elements that are muted or unmanaged.

I'd probably have an automated scheduled task that runs once daily and queries for Unmanaged Nodes and the date of that change.  If the difference is 14 (or whatever) days from today, then delete the node.

I was able to execute the alert action. I need to enable the below option in the polling setting and the alert works for unmanage nodes as well 

Thanks KMSigma.SWI and bobmarley  

Glad you got that going! Happy to help any time!