Hm, thatâs tricky. You may have read it through already, but if you havenât, take a look at Tip - Action Override User settings
I think this falls into a case I didnât try, though - if I understand correctly, you want the PS1 script to execute under the specific user account, with elevated privilege, but display no interface to any logged-on user. Most of my work was in trying to get the user displays to work, or to elevate the logged-on user. But maybe something from that post can help if you take one of the working password options and experiment with the âtargetuserâ parameter (or leaving it out).
I can say you wonât be able to use the âaction override passwordâ option this way -
parameter "action override password"="mypassword"
Itâs not the spaces though - itâs the fact that the Console will still try to add its own parameter of the same name, causing a duplicate parameter.
The âaction override passwordâ parameter needs to be a Secure Parameter, and set before the action is issued. Usually the Console does that part for you (the console specifically looks for the âpassword=requiredâ override option and pops-up the credential dialog). Thereâs a bit of discussion of Secure Parameters at Secure Parameters .
Iâm afraid Secure Parameters are a poorly-documented area, Iâll try to write something more detailed when I get some time, but the main things to understand are
-
They donât work with WebUI (thereâs no interface for handling Secure Parameters there). They work with the Console, using embedded JavaScript in the âdescriptionâ tab to override the âonTakeActionâ event. They work with REST API as well using XML fields
<SecureParameter Name="secret">SecureValueOfSecret</Parameter>
<SecureParameter Name="secret2">SecureValueOfSecret2</Parameter>
-
They cannot be dynamically-targeted. The Secure Parameter is encrypted individually to each target computer, using that clientâs public key. This ensures no other computers can decrypt the secure parameters, but also means that we cannot dynamically-target the action.