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.