JSS script parameters are a great feature that allow you to create scripts that can be flexible in the values that are gathered. I’m not sure how often they are used but suffice to say they can be very useful when you have scenarios where common commands are used repeatedly and just need variables changed. Parameter labels can also be assigned to JSS parameters as shown in Rich Trouton’s blog post. Parameter labels can also be set by going to Settings > Computer Management > Scripts > clicking on the script and selecting the Options tab. This allows you to go from the generic Parameter 4, Parameter 5, etc. and have something more descriptive like “Free Space Required” or “Custom Trigger”.
However, JSS parameters have a few limitations. Below I’ll go over some of those limitations and the associated feature requests that would address them.
Character Limits to JSS Parameter
Currently if you try to enter a value longer than 255 characters in a parameter field in a policy’s script payload, the JSS will automatically cut off everything beyond the 255th character. This used to be a limitation of MySQL prior to version 5.0.3, but it no longer is. You can store up to 65535 characters in a Text data type field as described in the MySQL 5.5 Storage Requirements document: https://dev.mysql.com/doc/refman/5.5/en/storage-requirements.html.
Only 11 JSS parameters
JSS parameters currently have 11 JSS parameters. The first three are dedicated for are predefined as mount point, computer name, and username. Parameters 4-11 can be used by the admin as needed. Depending on the script, the 7 parameters may not be sufficient.
JSS Parameters are visible
Currently all JSS parameters are visible. There is no support for obscured fields where one might want to input sensitive parameters. Granted, it’s probably not a good idea to put username and passwords in a JSS parameter. This has led to the creation of projects from JAMF IT: https://github.com/jamfit/Encrypted-Script-Parameters. The name is a little misleading as the parameters are not encrypted but rather just a way to obscure the password. It’s not secure, but it tries to at least add another layer to make things a little more difficult. It would be great if JSS parameters were simply encrypted to begin with and decrypted in a secure manner on the client.
Script Parameter Types & Mandatory Parameters
A problem that can easily occur with JSS parameters is that some of them are required otherwise the script will break and not run properly. And depending on the script, this can be disastrous. There is a need for having required script parameters that would force the Jamf Pro admin to fill in the parameter field. Along the same lines, some parameters need to be of specific types (strings, integers, floating point (decimals, bool (true/false)). The ability to specify those types for JSS parameters would all the JSS to validate the values in those parameters before the policy is saved. Currently these are two areas that you would need to validate in your script. Sure, you can trust that the admin is putting in the right value and that’s simple enough if it’s only one admin, but if you’re dealing with multiple JSS admins then all bets are off.
Script Parameter Labels Character Limits
JSS Parameter labels have a 40 character limit. This can be problematic when you have to have labels that are a bit more descriptive and you want to provide an example. As an example, say I’m working on a OS script and one of the parameters is to provide a full path to the installer app. I would ideally like to put a label of: Full OS Installer Path (e.g. /Applications/Install macOS Sierra.app). But that isn’t possible because of the character limits. An increased character limit for Parameter labels would be nice. Perhaps 100 or 140? Or better yet, have an “i” icon next to the parameter label where you could provide a description of the parameter. The idea being if the person wants to know more they can either click on the “i” icon or hover over it with the mouse and get a tooltip popup.
That’s all I have for now. If you have additional ideas on ways in which Jamf can improve upon JSS parameters, feel free to leave comments below or make your own feature requests and link them in the comments below.