May 8, 2017 at 9:09 am #5527Steve MasonParticipant
Hi all. As mentioned in another thread somewhere here, I’ve switched from Autoit to Powershell for pretty much all of my scripting. Anything truly automated I use PDQ Deploy for. We have a number of applications that we don’t necessarily deploy automatically, but are “as-required” and the users just launch the install from a shared folder. In the past the shared folder had a shortcut to the compiled Autoit script. Now we have a shortcut to a .cmd file that launched the powershell script like:
Powershell -file “\\server\share\product\installscript.ps1”
This works just fine, but seems a bit, well, sloppy. I could compile the Powershell like I did with Autoit. How does everyone else handle launching ps1 files?
May 8, 2017 at 10:52 am #5529Bob KellyKeymaster
Hi Steve, great question. I think a cmd file is pretty standard, but agree it isn’t the best presentation for an end user. This was actually the original problem I was trying to solve with the Script Packager feature of the Admin Script Editor. Some scripts need a command line interpreter, and other possible external dependancies which even make delivery even more of a challenge. PowerShell isn’t a language that can be “compiled” but it (and anything really) can be packaged. The result is essentially a self extracting executable that cleans itself up after running out of the %temp% folder. It doesn’t sound like your environment is locked down, but the feature also supports the setting of alternate credentials so that users that don’t have permission to install the software, could do so without prompting.
Or see the Script Packager closer in this video:
May 8, 2017 at 12:56 pm #5530Steve MasonParticipant
Thanks for the reply. I guess you’re correct that PS can’t be truly compiled, the PowerGUI Script editor has a compile feature that generates a .exe but I suspect it’s probably very similar to Script packager. The one time I tried PowerGUI to compile a script, it happened to be one that took arguments, that PowerGUI doesn’t handle well when “compiling”
We definitely DO have %temp% and most of the user profile folders locked down via software restriction policy to help prevent ransomware.
May 8, 2017 at 3:15 pm #5533Bob KellyKeymaster
The way the ASE Script Packager handles arguments is that it exposes it as an environment variable you can parse in your script. The full command line is to be handled as a string by reading %ASEEXEARGS% where you can take actions based on what you find accordingly.
Having %temp% locked down is rather unusual, this is the default target for extraction and execution because most every user is able to write here– if you have designated another location for such it can be specified in the settings for the Script Packager.
You must be logged in to reply to this topic.