Would like to request a feature where I can checkmark 1 box in a policy that instructs the client to download all content in the policy (packages, scripts, etc) before executing.
Current need for this feature is distributing an upgrade for our VPN client. Deployment needs the VPN client (package 1) and the config file (package 2). Since VPN gets disconnected (if the user is currently on VPN) after the client is upgraded, the installation of the configuration file fails. Being able to cache everything then execute would fix this issue.
Other benefits of this feature would give a better customer experience as the content can be downloaded before its ran which would make that process a lot quicker. I do understand there are other ways to do this (smart groups packages for installing cached packages.
While this may work fine in practice, it adds a lot of unneeded complexity that could be solved by making this option part of the package as a whole. The simpler the deployment, the less that can go wrong and if something goes wrong its easier to troubleshoot.
Set policy to run once per computer when the script exit code is equivalent to a success.
For instance, if a large package fails to download successfully, and triggers the policy to fail, it should not count as the "once per computer" execution.
Please upgrade Jamfcloud to Java 8. As of today (2017/05/14), Jamfcloud is running 1.7.0_121.
As stated in this feature request (which is marked as complete), "With Java 7 going end-of-life in April 2015, we're only about 4 months out from security updates ending for that product."
In addition, Apple's GSX program does not support Java 7 any longer. Attempting to use the GSX integration on Jamfcloud today will result in a Java SocketException error if the JSS is running Java 7, and is not usable. This is functionality that is documented as working for Jamfcloud, but it currently doesn't: https://www.Jamf.com/Jamf-nation/articles/26/integrating-with-apple-s-global-service-exchange-gsx
Being able to assign an app priority for MDM apps would be a huge help! We have some apps that are more important than others for our employees. To be able to have those apps download first would ensure we cover the important apps first during handoffs and deploys.
In Apple's Profile Manager, it is possible to manually create a Custom Confgiruation Profile Payload by specifying domain, key, and value without having to upload a pre-formatted plist. This is far easier to manage when you want to make adjustments, as it does not require re-creating the entire setting from scratch (or storing plist snippets somewhere). It very closely resembles manual MCX as implemented in JSS 8.x, a functionality that was removed in JSS 9.x.
Apple is still supporting and recommending the use of the Custom Config Profile payload to mimic the older custom MCX functionality (for example, this article about managing Safari Plug-Ins http://support.apple.com/kb/HT6168).
It would be supremely helpful to have this capability in the Custom payload, as the Manual MCX settings are tremendously flexible and powerful.
There are already features in existence developed by the Jamf community by talented individuals for some time now that Jamf needs to incorporate if they trulls want to support Mac Admins in the business arena and not just stay barely ahead of new Apple features.
I speak of two lacking features developed by non Jamf employees;
Local Administrator Password Solution
Both should have been a part of the Jamf Pro set by now as they are without a doubt well within Jamf's ability to include and much needed by Mac Admins.
When updating anything in a device record with the JSS API, the "Last Inventory Update" becomes wrong because it reads the API push as an inventory update instead of just a record update.
The "Last Inventory Update" field does not get updated when editing the device through the GUI, so it is quite aggravating when it updates through the API.
It would be nice to have a different way to calculate the "Last Inventory Update" and maybe have a new field that reflects when anything is changed, whether it be with the API or the Web GUI. Maybe even include who updated the device record.
Sounds minor, but a very frequent annoyance that would save a lot of time on repetitive tasks:
When listing a specific version number for a smart group, the versions for patch-management titles are currently in ascending order. This means that to update a smart group, I need to scroll to the end every time, instead of choosing the item near the top of the list.
Ex: To update my smart group for Firefox, I need to scroll PAST a full screen's worth of entries to get to the current (53.0.2). Having the versions in descending order (and a way to purge old versions from the database so I don't even see entries for 3x.0) would be nice.
This was actually a bug, and we fixed it in 9.99.0.
When classes are deleted in Apple School Manager it would be good if Casper also deleted them when the sync happens. Or introduce some way of bulk deleting classes. We had an issue with our naming convention and decided to recreate the classes in ASM. This means we now have every class twice but the old classes are not connected to Apple School Manager. The only way to delete a class is to go into each one individually and delete.
Currently the JSS performs package verification prior to copying the package locally to the system. For systems on slow link connections or high latency connections this adds significant time to the deployment process. By copying the file locally to the system first, then performing the hash check significant load can be removed from the server (technically 50%) since the file is only being transferred from the server to the client once. This will also improve package deployment times for everyone because there will be less network traffic and performing the hash locally will be much faster. I see no security benefit to performing the hash when still on the server as the file is still being read through by a client side process. If this change is adopted and the hash does not match the jamf binary can just delete the downloaded (possibly corrupted) file. I do realize we can turn verification off entirely, but verification is good, I just ask that it is done in the most effective manner for the overall system.
Package validation now occurs after the package has been downloaded. Packages will be validated if you choose "Always" or "When checksum is present" from the Package Validation pop-up menu.
To access this feature in the JSS, navigate to Settings > Computer Management > Security.
The hashing algorithm has now been improved for JSS user account passwords that are stored on the JSS server.