Script Packaging Step-by-Step: Adding Restrictions

In this installment of our Script Packaging series, we review the options for adding restrictions when running your packaged script.

Sometimes running an application on a platform that is not supported or under conditions that are not secure can do more harm than good. For example, a script to install Windows XP service packs should probably not run on Windows 7. Of course, one would hope the installer would catch that, but who knows?

When you package a script with the SAPIEN Script Packager, you have an assortment of options to prevent a packaged script from running under some conditions.

Operating Systems

At the top of the Restrictions page is a selection of OS versions:

If checked, the application will only run on the OS versions you marked. You may ask why Windows 11 is not on that list. Technically, Windows 11 still represents itself as Windows 10, so the current mechanism would not catch this. You can expect an update to this in a future version.

Users, Devices, Environments

The second set of restrictions are fields where you can enter semicolon-separated lists of items that designate where the application is allowed to run:

For example, if only the users ‘Administrator’, ‘Caleb’ and ‘Lucy’ are allowed to run your application, you would enter this in the User name field:

Administrator;Caleb;Lucy

You can apply the same use of semicolon-separated lists of items in the other fields: MAC address, Machine name, and Domain.

Instance, Script Block Logging, Script Block Transcripts

Allow only one instance is fairly self-explanatory; if your application is already running, you cannot start it again.

The last three boxes only apply to PowerShell. These options either prevent a launch with script block logging, or turn off script block logging and/or transcripts. Because script block logging and script block transcripts only exist for PowerShell, these options are not available for any other type of engine or scripting language.

These settings are commonly used for scripts which contain items you do not want the average user to see. If, for example, your script needs to connect to a legacy database on a server with an administrative user and password, you do not want the average user to be able to find these credentials in a log.

We have other ways to deal with that last scenario, so stay tuned for the next part of this blog series.

Related

Feedback

Any comments or suggestions? Please post them in the comments below or in our support forums.