Powershell Script Issue - "Cannont Run scripts"

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.

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.

1 Like

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.

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

1 Like

I am looking at this now. Thank you!

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

2 Likes

This Tip post may be helpful too

1 Like

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

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.

1 Like

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!

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.

1 Like

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.

2 Likes