Please integrate with git (GitHub / GitLab and or BitBucket) and empower us to do version control for our scripts. There is too much complexity in scripting to not have a revision history. The workflow needed to accomplish this right now is clumsy and requires making extra policies and a lot of copy and pasting.
Version control is a feature that will raise Jamf up among the software industry by a lot; an industry that is being dominated by macOS devices.
(Side note, if anyone is doing this right now with the Jamf API or otherwise, please let me know how!)
Since we have a standard naming convention for our computers, we make Smart Groups using the Like "type". But some other computers have the same criteria in the middle of the name, therefor they are included in the group.
It would be nice if Starts With and Ends With would be added for a Criteria "type". That way our groups are more accurate.
When connected to ASM, currently subsets of users can be imported using Course, Class, Grade, or Managed ID as filtering criteria.
It would be helpful to add location as a filtering criteria as it would prevent the creation of extraneous records for districts that have multiple MDMs in use.
Also, it would be helpful to scope by location as well.
The Patch Management Definition for Skype for Business currently shows Skype for Business as the only app that must quit. The Skype for Business installer (there is no updater) also requires that Safari, Firefox, and Microsoft Outlook not be running.
I would like to see JAMF implement a system similar to Apple's https://bugreport.apple.com where I can log in and see the bugs I reported and their Defect Number. It would need to improve on Apple's system in some areas, but some of the key points are:
1) Access could be limited to the primary contact for an account, but I would like to see something more like Open Radar, http://openradar.appspot.com/, where others can see some basic info that would allow them to vote up and comment on a bug if they are experiencing the same issue. This would also help JAMF prioritize bugs.
2) This would allow tracking the progress of the bug so people don't need to keep bothering JAMF support or their account reps for the status of bugs.
3) This would allow JAMF to create a bug reporting form that ensures specific pieces of information needed for a proper bug report. For example Casper version, rank from critical to non-critical, exact application affected (ex. jamf binary, jss, Recon, etc.), steps to reproduce, etc.
4) This would give internal JAMF programmers and the person that originally reported the bug a more standard and consistent way of communicating regarding a specific bug.
Currently if you use a description in a Self Service policy that it is longer than the Description field area, there is no indicator that you can scroll down or that there is more text to even read. Before Jamf Pro v10, you use to have a scroll bar that would allow you to scroll down and at least acted as an indicator to read further. Given that the Self Service description popup is not even taking up the entire Self Service window, I would really love to see this improved.
In the current versions of the Casper Suite, either series 8 or series 9, we have the ability to report on almost every piece of data stored for computer records, and in many cases can also access these data items via the Casper API.
The one major exception to this is the FileVault 2 Recovery Keys. Although I can read every single key for an encrypted Mac, one by one, due to my privilege settings, I can't generate a report on all Macs \+ their respective individual keys. The item isn't available as a column to add in to a search. To add to this, these keys also aren't displayed within a Mac's API record.
This is all partly because of security, since the keys are stored in an encrypted state within the database. I get why we don't want to have these in an easily readable state. That's a good thing. However, we consider the fact that Casper Suite is the ONLY location where those very important keys reside to be a bit of a flaw. For the purpose of even higher security, and also redundancy, we don't allow all our techs access to the Casper Suite. We need to be able to pull these keys along with some other computer details into another database where they can access it with elevated rights accounts. Not being able to export these keys into another system or access them in some scripted manner means we're unable to do so.
Please add the ability to both-
a) Run an Advanced Search to list the Individual Recovery Key for each Mac, if one is present and one has the Privileges to see those keys
b) Access these keys from the API or some other secure method so we can script pulling them into another system.
Even simply being able to export them into a csv file right now would be a big improvement.
It would be really convenient if within the scope of a policy on the JSS console the scoped computer(s)/computer groups etc were clickable.
I know it's pretty simple and petty, but it's a pain in the ass going and searching for a smart computer group to manually go into when it's sitting there listed in front of me already.
We have been doing some cleanup as we get ready to move from 10.8 to 10.9. Since we are trying to use this time to switch as much as possible to config profiles, we creating new clean smart groups for 10.9 machines. Are old smart groups aren't as organized though and at one point some people were using them for reporting, but not actually scoping them to policies. It would be great to go into a smart group and have a "where used" option. That way we could check the policy that is using it without having to audit everything. We are currently running JSS 9.22.
We recently revamped our user permissions and discovered there isn't an easy way to tell which features require which permissions.
A prime example is recon; in order to use/open recon you need these permissions:
If recon hadn't given one of our technicians the prompt telling us what permissions were needed to run it we'd probably still be playing with permissions.
I discovered yesterday that the permission we give some of our technicians don't allow them to update inventory or send blank pushes to mobile devices, despite having the appropriate boxes checked in "JSS Actions", so I figured it'd be a good time to request some actual documentation about what features require what permissions.