I'm trying to execute a simple, test powershell script (which works fine when I right-click it and run with powershell, .ps1 file) from SSIS. My ExecuteProcess task has these parameters:
Executable: PowerShell.exe
Arguments: -F "D:\Users\Folder\Working Files\Teton Information\TestPowershellScript.ps1"
I get back exit code 1, failure. What am I doing wrong ?? I've tried it with and without quotes
July 17, 2024 at 8:35 pm
This was removed by the editor as SPAM
figured it out ... had to set the execution policy to bypass
and adding a -noexit switch on my arguments line helped powershell remain open to help me see what was wrong
July 18, 2024 at 9:20 pm
My opinion - setting the execution policy to bypass is a bad idea on a desktop and a horrible idea on a server. Sign your script instead.
The reason it is bad is that change is a global change, not specific to your script (if I remember right). SO any powershell script that ends up on your machine can be run without any warnings and powershell can do all sorts of harm to a computer. It is MUCH better to have the script signed and thus trusted.
The other advantage to signing your script is that if it gets modified AND the signing isn't updated, the script won't run. This helps protect your server in case someone tried to modify your script to do harm to the server.
BUT it is entirely your call how you do it, but I don't run any unsigned powershell scripts on my machine or servers. My policy is that I only sign scripts that I personally have verified. If I have signed it with my key, it means that I looked at the script AND I said it was good and that I am responsible if there are issues. I put notes about who signed it in a comment in the script boilerplate.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
July 18, 2024 at 9:28 pm
setting can be applied on the execution of the script itself - changing global policy is bad - but changing to execute a internal script with the setting on is not quite a risk
July 18, 2024 at 9:45 pm
Hi Brian, I am very receptive to the advice, as I'm new to Powershell - very new. However, rest assured that in this case I was NOT doing the thing where you open Powershell as an admin and set the global setting to bypass or whatever. I was only using it on the command line arguments for this one script run.
I will have to learn about signing scripts. I am a dev, not an admin, where I work, so hopefully it doesn't involve too much high credentialed stuff. But your message is well received and I will take seriously the signing and hopefully learn how. Thanks
July 18, 2024 at 10:06 pm
If you want a NICE tool for signing powershell scripts, I recommend this one:
https://www.idera.com/productssolutions/freetools/powershellplus/
Idera Powershell Plus. FREE tool which is always a huge plus, and it works really nice for script signing once you figure it out.
I do NOT work for Idera, I just really like that tool and REALLY appreciate that they made it free!
I also was not aware that you could apply security policies on a single powershell script. I had thought it was per session or globally... guess I have a bit to learn too. BUT since I sign all of my scripts, it isn't too big of a deal for me. BUT is good to know!
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply