Powershell Script Issue - "Cannont Run scripts"

[Froggie]

Hello,

Im trying to run a action script task that runs a powershell script to connect a printer to an end device.

Here is my script

if { not exists folder “C:\software\Scripts” }
waithidden cmd.exe /C mkdir "C:\software\Scripts"
endif

parameter “baseFolder” = “C:\software\Scripts”

waithidden C:\Windows\System32\icacls.exe {parameter “baseFolder”} /grant “Everyone:(OI)(CI)F”

delete __createfile

createfile until end
Add-Printer -ConnectionName \sup-ap-pwvprint\acct1
start-sleep -seconds 15
end

copy __createfile {parameter “baseFolder”}\corpprints.ps1

waithidden { pathname of file ((it as string) of value “Path” of key “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell” of native registry) } -ExecutionPolicy RemoteSigned -File C:\Software\Scripts\corpprints.ps1
pause while {exists running application “powershell.exe”}

waithidden powershell remove-item -Path C:\Software\Scripts -Recurse -Force

When I try to deploy it as a task this happens.

I have tried every way under the sun to set this to ByPass the Execution Policy but nothing is working.
I have tried running this as a PowerShell script, action script. Tried changing the script around 10 different ways, making variables to hold the information to running the script as you would normally. I can run this script No issue from the desktop. It works just fine no issue from PowerShell. Only when i run it as a task does it fail like this.

The user running the task is a DomainAdamin as well. Not sure why its happening.

Does anyone have any ideas or tips to try? This would save me a lot of manual time if I could just add printers from the server through a task.

[JasonWalker]

Normally we’d use -ExecutionPolicy Bypass when executing PowerShell scripts.

I’m not sure whether the script requires connecting to the print server, but keep in mind it’s executing as LocalSystem, not as the logged-on user, so it may have problems authenticating to the print server - but you’ll need to get the script to execute first anyway.

[Froggie]

I have set it to ByPass and unrestricted.

I think the issue is that it is running as LocalSystem. That would make sense.

This was just the final iteration I gave up on, I think i rewrote this seven different ways.
Thank you for the insight.

[ageorgiev]

You can do an override and specify the account to run this under, it will overcome the LocalSystem issue.

[Froggie]

I am looking at this now. Thank you!

[ageorgiev]

https://developer.bigfix.com/action-script/reference/execution/override.html

[JasonWalker]

This Tip post may be helpful too

Tip - Action Override User settings

This post is an attempt to demystify some of the ‘action override’ parameters and to provide some useful examples. General Considerations When running a script as a user, the normal user account generally does not have access to the __BESData directory or subdirectories. After creating a script with ‘createfile’ or ‘appendfile’, or after downloading a file through ‘download’ or ‘prefetch’ commands, the content needs to be copied to a directory the user can access. Avoid using the ‘move’ com…

[Froggie]

So is there a way to obscure the password in the action so anyone who uses this wont be able to see it?

[JasonWalker]

Just to be forewarned, you’re jumping in the deep end here. I haven’t had a case where I needed to supply a password for things like this, and if we did, it would be the end-user’s password on the client (since printer mappings are per-user, it doesn’t do any good to map it with one of your own accounts, the end-user wouldn’t see that).

You should probably use one of the overrides like runas=currentuser, so the PowerShell executes in that user’s context and you won’t need their password - but they do need to be logged on to the machine when your action executes.

[Froggie]

Youre right. I was getting the feeling this isnt the best way. I will talk with my team mate and see where im going wrong internally. It may just be my novice experience affecting the action.
Thank you for the advice!

[ageorgiev]

You don’t need to put the password in the actual action. In the below example, the only thing you really need to change is the account (leave password=required) and when you run the action it will prompt you for the actual password and it is not visible anywhere

override wait
    runas=localuser
asadmin=true
user=TEM\User1
password=required
wait c:\IMAGE\SWD\application.exe /SILENT

Jason is right though - this is rare… I only ever needed this once for a very specific use case - in my situation the job needed to make connection to SQL database using Windows Authentication and running it with specific domain user was the easiest way to do it.

[Froggie]

After fighting with this I was eventually able to get the issue worked out. Thanks to all your alls help!
I was over thinking it and making it way more complicated than it needed to be.