I don't know about others, but I find it confusing to know if a restriction is enforced with the current layout of options. I feel like there should be three ways a setting should be visible in the Configuration Profiles windows:
1) Enforced to On
2) Enforced to Off
3) Not Enforced (user controlled)
This could either be two rows of checkboxes in the window or some sort of new interface that would allow an admin to choose which specific options are "turned on" or "applied" to the profile.
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.
It would be very useful to have finer control over the jamf flushPolicyHistory command.
Similar to how the [code]jamf policy -id 123[/code] command allows triggering a specific policy on the client, I would request the ability to execute [code]jamf flushPolicyHistory -id 123[/code] to flush the policy history of that client for that policy, as can be done via the JSS web interface.
This would allow you to automate the removal with 1 policy caching until a certain date, & another uninstalling the cached item after the date has passed.
Also, could be used to make sure that a newer cached version is installed. Much like we so with DMG's for apps.
Current Deferral Limit settings for policies are a fixed date/time. For ongoing policies this is a pain because, once the date passes, you either lose a deferral period entirely, or you have to extend the deferral date indefinitely, which means the policy may never be applied. I would like to be able to set a deferral limit of %n number of days since first deferral or %n number of times from first deferral, allowing a set grace period before policy enforcement regardless of specific calendar dates.
As of Chrome 58, certs that do not use the subjectAltName field and fall back to the Common Name will produce an error, even if the Root CA is trusted by the OS. Firefox is also requiring SAN, and it is likely that other browsers will follow. It would be helpful for the JSS Built-in CA to include the SAN field on the ssl certs it generates. This would prevent the errors for computers that are enrolled to the JSS and are set to trust its root.
It would be useful to have a computer's local hostname (short name) displayed in JSS inventory. This hostname is used for binding to Active Directory and is how the computer is identified to other devices on the network. It may be unique from the full Computer Name currently displayed by the JSS.
The hostname can be found in System Preferences under Sharing. See the following Apple knowledge base article for more information:
Apple Knowledge Base article PH18720 (written for Yosemite but still valid for Sierra)
We have quite a few policies that prompt the user to quit applications and install or select later,
currently i have these running on a once per day basis but i feel the need to be a bit more aggressive with the prompting ;)!
To do this at the moment i'm duplicating the policy and making an AM and PM version limited to a time frame but it would be very useful if there was an option to run a policy 2, 3, 4 times a day.
At the moment you can only assign a policy or smart group to a single site. It would be nice if this could be done on multiple sites with a checkbox.
this would then allow the use of global policies and smart groups for packages and scripts that need to be deployed to all.
Maybe i'm not getting the purpose of a policy's scope limitations right, but why can't i add a smart group? If i want to scope a policy to all my users that have x.app installed, but limit it to Macs that have OS X 10.10.x, why can't i add my 10.10.x smart group? I suppose i could either create a separate smart group that does the limitation i'm looking for, or exclude all other OS version smart groups using the "Exclusions" tab. But wouldn't this be more practical as a limitation?