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)