Im not sure that parameter "action override password"="mypassword" is valid syntax (I’m not certain whether spaces in parameter names are permitted, but it doesn’t feel right), and you certainly don’t appear to be using it later in the script
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
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.
I am pretty sure I do something similar but I will have to find it. We do it by making a batch file and then running that. As long as the system is on the domain, the system will be able to authenticate with its domain account and grab the file, then execute it from the batch as well.
Found it
Looks like we actually run it from the netlogon DFS
Nice one!
By default a Computer Account cannot reach network shares, with the domain NetLogon share being the exception.
Not recommended, but you could enable other shares by adding “Domain Computers” to the “Access this computer from the network” in the Rights configuration of the security policy and to the Share Permissions and NTFS permissions.
(edit: Don’t do this unless you fully understand the ramifications. There’s a reason Computer accounts are excluded from this right, and from the “Domain Users” and “Everyone” groups by default)