Skip to main content
Jamf Nation, hosted by Jamf, is the largest Apple IT management community in the world. Dialog with your fellow IT professionals, gain insight about Apple device deployments, share best practices and bounce ideas off each other. Join the conversation.

Will JSS 10 finally bring us easy patch management?

We tried to get @gregneagle to speak at JNUC2014. Your's truly offered to walk on stage in a tutu, introduce him, and walk off stage, stoping to curtsy along the way. Such a golden opportunity and he declined (OMG THANK YOU!!!). ;)

Posted to IRC today:

Direct link to image:
external image link
Direct link to the relevant feed:

A couple years ago we had a JNUC session where JAMF sat with some of the large clients and discussed the upcoming version, and what we wanted/needed in the new version. I came prepared, suggesting (1) exclusions and (2) ring fencing. Both requests made it into JSS 9 (as exceptions and sites).

I really hope JAMF does the same at JNUC2014, so we might finally get new patch management functionality in JSS 10. Whether it's something simple like adding is equal to or greater than to Smart Computer Group criteria (not sure that would be reliable in all scenarios), or some other way of determining if an installed piece of software needs to be updated.

external image link

@loceee's Patchoo (gesundheit!) got a lot of attention, as it showed, at least conceptually, what might be possible if JAMF could dedicate some time/resources...:

Hello junki! Casper patching done right!

...and it stirred up a lot of discussion; if you're not already on the ##osx-server IRC channel, do yourself a favor and join. Scroll to the bottom of:

Don't miss @tbridge's excellent IRC article:

The more attention this gets, the greater the chances JAMF might pull this off...hopefully without anyone needing to parade around in a tutu at JNUC2014.


Like Comment
Order by:
SOLVED Posted: 6/18/14 at 6:18 PM by scottb

@donmontalvo: Great stuff, Don. Also glad there are no pics of you in a tutu. I mean, you're a handsome guy and all, but I have enough of that with the guys I work with...not naming any names. :)

SOLVED Posted: 6/18/14 at 6:20 PM by donmontalvo

@boettchs Um, thanks, I think. :D

SOLVED Posted: 6/18/14 at 6:41 PM by mrowell

@donmontalvo Agreed.

Casper has totally streamlined how I manage our macs. Now the biggest ongoing management job I do is deploying software updates. I have to download them, package them, upload the package to JSS, manually adjust two policies (install and update) and a smart group to deploy the package to a test group. Then I have to come back and adjust another two policies (install and update) and a another smart group to deploy to production. I have to do this multiple times a week.

Munki with autopkg makes this workflow, the most common thing I do with Casper, so much simpler.

I use autopkg with @Banks JSS autopkg contributions to get software that has .pkg recipes into the JSS (Big thanks Allister!). But that solves only one third of the issue.

I would really appreciate having a more streamlined workflow getting updated software into the JSS, tested and then out to production.

It should be as simple as: 1) New App update is automatically downloaded and added to the JSS (using autopkg or the like).
2) New App update is automatically deployed to test group & admin is notified.
3) Admin validates App update is working.
4) Admin logs into JSS, goes to App policy and selects version to be installed to production.
5) New App update is now automatically available in Self Service, new installs as per policy and updated if installed.

SOLVED Posted: 6/18/14 at 8:35 PM by loceee

Yes I would come all the way from Australia just to see that @donmontalvo :)

After building patchoo and having to fit it into existing workflows my opinion is software deployment and post deployment patching needs to be revamped. I am pretty darn happy with what I've managed to wring out of group, policies and triggers, and the Patchoo feature-set could be a good stop gap in between the future and now. Putting in some smarts for version comparison as you've mentioned would make life a fair bit easier too and should be a reasonably easy extension.

BUT... in order to fix it properly here's how I would do it.

Computer configurations need to be extended and pried out from Casper Imaging's exclusive use (ain't no one imaging in the town anymore). Extending configurations and making "software groups" that allow grouping software together that aren't standalone computer configurations, so we can build more granular and nested groups (as munki can nest manifests), would be great (eg. creative software- could contain CS and a font manager). We need to attach pkgs to pkg_identifiers (pkgs shouldn't be floating around with no association), and have Casper work out (via version comparison, pkg receipt db queries and extended client smarts) what needs to be installed. Computer configurations should be manifests in munki-speak. Attaching a client to a Computer Configuration is all you should do. Updating or deploying a piece of software should be as simple as dragging a pkg into the configuration or software group you choose. Casper should do the rest and take care of the logic and process to bring your clients in line. We need more metadata in the JSS DB for pkgs to accomplish this, and as much of this as possible needs to be read directly from your pkgs to limit manual input as well, just as munkiimport does all this heavy lifting.

I agree 100% with @gregneagle. These are the bits miss most from my days as a Radmind and munki admin (I only came to full-time casper admining a couple of years a go). Tell admin system what I want as a final result, admin system takes care of the rest. Having to manually create groups to catch clients, then apply a policy to said group is far too admin heavy. Even if I automate most of it with Allister Bank's super cool JSSImporter for autopkg (which is my next mission), it's still a bunch of stuff we shouldn't have to do for something as basic as ensuring a group of clients have v x.x of AppName installed.

Thinking out loud... the main reason I gave up trying to get munki integrated was because said Computer Configurations weren't exposed via the API... (ahem \- ) If they were, I actually think we could shoehorn munki into Casper. Computer configurations could be used to generate manifests. Pkgs are already exposed via the API, so they could be fed into munkiimport and processed.

We could use a number of methods to link clients to said configurations. A few custom triggers, and a policy here or there. Maybe... maybe...

To mirror the sentiment of the thread, it's not really my job though :)

SOLVED Posted: 6/18/14 at 10:17 PM by colonelpanic

I plan on presenting some of this at this years JNUC, but I'll share how we do our patch management...

We have 3 scripts. We have a software scanner, software update script, and security patch script. I'll break them down below.

The software scanner is a pretty simple script. The primary purpose of this script is to scan the current versions of software on the machine and if it doesn't match the latest version, it will output the application name into a text file. It will also run a softwareupdate -l if the software scanner is being called by either the security patch or the software update script (more on that below). It also collects information about whether or not the install will require a restart, if it is an urgent update, and other tiny bits of information. If the update is urgent (like a java update to fix a zero day), it will actually install the software immediately. This script is run on the every30 trigger, and additionally once a week with notifications turned on. When the notifications are on the user will receive a cocoadialog bubble notification letting them know that a certain piece of software is up to date and presents the icon of the software.

Next we have the software update script. This script is usually run from Self Service, but it can also be called by the security patch script (we'll get to that later). This script will call the software scanner, and then install any software that is in the text file that the software scanner left. It uses a cocoadialog progressbar to let the business partner know how things are going and what software is currently being installed. At the end, if a restart was required, it will prompt the user to restart.

The security patch script was created because of our compliance needs. Per many regulatory requirements, we must run a "security patch" once a month. The security patch script actually runs daily on machines, but it phones home to check what the pilot group enable/enforce dates are and the production enable/enforce dates are. The enable date is the date in which the patch is available, and the enforce date is the date in which the patch will be forced. Users have 5 days to install the security patch once it is live. During the first 5 days, the users are presented with a jamfhelper pop-up telling them that updates are available, and it also lets them know what the enforce date is and if a restart will be required. It runs the software scanner to figure out if software updates are available and if a restart is required. If there are no updates then our maintenance plist is updated to reflect that this month's patch was run on the machine. We enable it for our test users first (the script just looks for a flag in our maintenance plist to see if they are in the pilot group or not). When the security patch goes to install software it simply calls the software update script.

I know I just kind of vomited words all over the screen and I'm not sure if this all makes sense, but be sure to come to this year's JNUC and there will be a session about this, and also about how the user interface can make or break your deployment process.

SOLVED Posted: 6/18/14 at 10:45 PM by nessts

tunic != tutu @boettchs

SOLVED Posted: 6/19/14 at 4:12 AM by yan1212

@colonelpanic thanks for this! Looking forward to your JNUC presentation.

SOLVED Posted: 6/19/14 at 8:26 AM by acdesigntech

We use the following patching solutions (used to be one unified script, but ... yeah...)

We have a finite number of non-system apps that are patched on a regular basis (flash player, popchar, silverlight, etc), so I've written an EA for each to grab the version and convert it to an integer for <= or >= comparison. The value of this EA is then used as criteria to add the computer to one or more "SoftwareUplift-XXXXXXXXX" smart groups. Then I have ANOTHER EA that grabs the group memberships of the Mac, and upon seeing any memberships in these "SoftwareUplift-XXXXXXXX" groups populates a Core Software Updates Available \- Yes attribute. Finally, I have a smart group with criteria 'Core Software Updates Available \- Yes' EA that I use as the scope for an overarching Core Software Patching policy. The policy basically does the same thing as the EA to grab the group memberships for each individual app update, but instead of just submitting yes or no, actually calls individual policies that have the same trigger name as the smart groups minus the version number since that frequently changes.

It sounds convoluted now that I've written it out (but now that it's all set up it's actually fairly intuitive and simple to follow \- oddly enough), and every time theres a new core software update I have to package it, upload it, change the individual smart group criteria for version number to get the updated membership, then wait for inventory to be submitted so the Mac falls into the appropriate group. I've done the same steps as above to create a pilot core software updates group so I can pilot for a week before moving to production, so inventory submission is never that big a deal.

If there's a new piece of core software that we wish to manage patching on, I create a new smart group for that piece of software, create a new patching policy to actually push out patches for that app, create a new EA to grab its version, update the Core Software Updates Yes EA to add that group membership, and edit my core software patching script with the new group name so it's now incorporated into the overarching policy. It's a LOT of work, but does automate a lot of the patching we do... Scripts below if anyone is interested.

'Core Software Updates Available \- Yes' EA:


## Set a flag to check if there are any updates available

## Get MAC Address using networksetup
MAC=$( networksetup -getmacaddress en0 | awk '{ print $3 }' | sed 's/:/./g' )
## Use the JSS API to get the Mac's group memberships
JSSGroups=$( curl -s -u username:"password"$MAC \
| xpath //computer/groups_accounts/computer_group_memberships[1] \
| sed -e 's/<computer_group_memberships>//g;s/<\/computer_group_memberships>//g;s/<group>//g;s/<\/group>/\n/g' )

NonSysCore=( 'SoftwareUplift-FlashPlayer' 'SoftwareUplift-Flip4Mac' 'SoftwareUplift-FontNuke' 'SoftwareUplift-MicrosoftOffice' 'SoftwareUplift-MicrosoftOutlook' 'SoftwareUplift-MSCommunicator' 'SoftwareUplift-PopChar' 'SoftwareUplift-StuffitExpander' 'SoftwareUplift-CiscoAnyConnect' )

for (( i = 0; i < ${#NonSysCore[@]}; i++ ))
    CheckUpdate=`echo "$JSSGroups" | grep "${NonSysCore[$i]}"`
    if [ "$CheckUpdate" != "" ]; then

echo "<result>$UpdatesAvailable</result>"

One of the Core Software Version numbers EAs:


if [ -e /Applications/Cisco/Cisco\ AnyConnect\ Secure\ Mobility\ ]; then
    AnyConnectVers=`defaults read /Applications/Cisco/Cisco\ AnyConnect\ Secure\ Mobility\ CFBundleVersion`
    IntAnyConnectVersion=`echo "$AnyConnectVers" | sed 's/\.//g' | cut -d ' ' -f1`

echo "<result>$IntAnyConnectVersion</result>"

Smart Group Criteria for Cisco AnyConnect:
Name: SoftwareUplift-CiscoAnyConnect 3.0.08057 (the name is important in order to automate this \- policy triggers are the same as the group name, minus the version number)

Hardware Information
  Model     like Macbook                
  Application Title     does not have Cisco AnyConnect Secure Mobility       (AnyConnect is new here so we're looking for computers without it for now. Later it will be based on version info)

The individual Cisco AnyConnect install/patch policy:

Name:   SoftwareUplift-CiscoAnyConnect 3.0.08057
Active: Yes
Frequency:  Ongoing
Trigger:    SoftwareUplift-CiscoAnyConnect
Scope:  SoftwareUplift-CiscoAnyConnect 3.0.08057
Plan:    Install Cisco AnyConnect 3.0.08057

The Core software patch policy to control the individual policies (this gets scoped to the Pilot \- Core Updates, Pilot Extended \- Core Updates, and Core Updates Available \- Yes smart groups):

Name:   Quarterly Core Software Updates
Active: Yes
Frequency:  Ongoing
Trigger:    every15
Scope:  3 computer groups
Plan:    Run Script Core Software Updates 1.0
 Update Inventory

And finally, the overarching core software uplift policy script that controls all our core patching:


########## Get the group membership for the client #####################
## Get MAC Address using networksetup
MAC=$( networksetup -getmacaddress en0 | awk '{ print $3 }' | sed 's/:/./g' )

## Use the JSS API to get the Mac's group memberships
JSSGroups=$( curl -s -u username:"password"$MAC \
| xpath //computer/groups_accounts/computer_group_memberships[1] \
| sed -e 's/<computer_group_memberships>//g;s/<\/computer_group_memberships>//g;s/<group>//g;s/<\/group>/\n/g' )

################ End Variable Set ################

## Use echo and grep to find known-core (non system) software update groups. If these groups are found, run these installers silently since no restarts are required for these updates. Use an array to see which updates we take account of. The names of the array elements are also trigger names for each update. This way when there's a new software package to keep updated, we add the trigger name into the array, and the update policy to the JSS. Casper does the rest
NonSysCore=( 'SoftwareUplift-FlashPlayer' 'SoftwareUplift-Flip4Mac' 'SoftwareUplift-FontNuke' 'SoftwareUplift-MicrosoftOffice' 'SoftwareUplift-MicrosoftOutlook' 'SoftwareUplift-MSCommunicator' 'SoftwareUplift-PopChar' 'SoftwareUplift-StuffitExpander' 'SoftwareUplift-MicrosoftSilverlight' 'SoftwareUplift-CiscoAnyConnect' )

for (( i = 0; i < ${#NonSysCore[@]}; i++ ))
    CheckUpdate=`echo "$JSSGroups" | grep "${NonSysCore[$i]}"`
    if [ "$CheckUpdate" != "" ]; then
        jamf policy -trigger "${NonSysCore[$i]}"

I've mirrored this workflow for OS patching leveraging the softwareupdate binary as well.

LOTS of manual work \- but worth it since Casper cannot manage software patching \- and this gives me an (mostly) automated method of doing so. It's extremely difficult for me to introduce new software and management frameworks here, so no munki for me. Essentially if it doesn't have JAMF, Apple, Microsoft, IBM, or Oracle in front of it \- I can't use it :(

SOLVED Posted: 6/19/14 at 9:46 AM by dpertschi

Yes- patch management causes me the most difficulty as well...

While more automation is a popular theme here, I'm interested in better built-in controls for end user interaction and distribution enforcement.

Distribution Enforcement
If we need to get a patch out fast, the existing triggers are just not satisfactory. Startup, login, logout are not helpful as half my user don't do any of those frequently (it is what it is), and self service falls out of scope for expediency. Recurring check-in would need to engage the user to either quit the target app or allow for a quit, update, reboot. Forcefully quitting applications and or rebooting without notice for patching is not acceptable.

So It takes advanced scripting skills to develop end user notifications which then require the user to select an option that will safely update what you need in a timely manner. The new deferment option is helpful but not quite enough. On these JAMF Nation forums, collectively, there are thousands of hours worth of custom scripting that address similar needs, clearly representing missing functionality many of us need. Personally, I'm just not a programmer.

While I'm not a big fan of forcing a user to stop working for updates and and a reboot, we need safe controls to do so.

Underlying that or in addition, we need built-in controls to ensure that the target application to be updated is not running at the time of install. In a policy we'd have a pre process check that looks to see if the app your updating is running and needs to be quit, then prompting the user to do so in order for the action to continue. Defer if you like but, ultimately falling back to a 'sorry you have to do this now' position.

Patch Compliance Reporting
I'm sure many of you are also required to produce patch penetration or patch compliance reporting. For me, this is another major hassle which involves a lot of manual calculations from the output of various smart groups that look for does or does not have version xyz of an application, based on a select target group.

Would love to be able to enter this criteria all into one form which is dynamically updated, visible in an access controlled web interface, and can be exported to Excel charts or a few select canned pdf charts.

And I bet these things could even make it into v9. JAMF has incredibly talented staff, many who came from our positions and understand these shortcomings in a production environment.

SOLVED Posted: 6/21/14 at 12:25 AM by mcrispin

so... tutu or not?

SOLVED Posted: 6/21/14 at 8:24 AM by donmontalvo

@mcrispin][/url :D

Such a golden opportunity and he declined (OMG THANK YOU!!!). ;)

[UPDATE] In response to all those who DM'd me in Twitter, asking for the Tutu...

SOLVED Posted: 6/27/14 at 10:24 AM by laurendc

I would love to see JAMF actually address this. Not sure if I can wait till 10 \- but a definite indicator that it would be at least addressed in 10 would go a long way for me. Patch management has been on the brain in recent times, and the amount of legwork I have to do to get what I consider a second-rate solution to work is non-sensical. I shudder to think of the position that I'd put my colleague in to hand-off or backup our current solution. He doesn't have a programmer mindset, nor should he be expected to have the amount required to get this to work "properly" when you have software that is supposed to do the heavy lifting for you.

At the moment, we have two things happening in my environment: 1) Two policies are set to run software update to keep us under compliance \- one to prompt users with deferral options, the other to actually do the heavy lifting with reboot included. This method gets the job done but still doesn't provide transparency to the user once they opt into receiving the updates. The machines reboots randomly after downloading them in the background. 5 minute warning included of course, but I'm with @dpertschi and @colonelpanic who acknowledge that the user experience can either make or break a deployment. We should not have to accept that reboots like this are OK, nor should we be expected, in essence, to work around what seems to be the function working "as expected". Graham Gilbert put it nicely in his blog post:

"... my goal is to make my client’s mac experience as awesome as possible, and random reboots with only five minute warnings aren’t exactly awesome in my book."

2) For non-system updates, there's a similar but different can of concerns to deal with. Due to lacking a maintenance window, our main choices for patching FileVault 2 enabled machines with users that never logout or login and do not have a wireless connection at the loginwindow, I have two options for pushing updates:

-Self Service
-Push with options to install in the background if the process/es aren't running or do any pre-install checks or requirements needed, plus user interaction if needed to quit apps, etc. So basically a script with trigger/s in it for the installation.

Either way, I've got a minimum of two policies going to make this happen, and the management of these mirrors what @mrowell is doing. With every update \- need to modify the policy, check the smart group/s, etc. Sometimes more than two policies, depending on the title and what we need. So in essence, I'm basically using Casper as a delivery mechanism for these scripts and updates. Which works well if you have minimal patching requirements. Not so well when you have more responsibilities outside of being the Casper administrator, and your patching requirements grow every year.

SOLVED Posted: 6/27/14 at 3:25 PM by dpertschi

JAMF staff monitors posts, so I do believe this is being seen. But maybe collectively we can put more visibility on this by commenting here frequently, bringing it to our account managers, and voting up this feature request...

Maybe we can convince JAMF to hold round table discussions each day of JNUC 2014 with 10-20 admins and really talk this out. Paint the picture of the hassles we encounter with patching and develop a list of potential feature additions to make this aspect less painful.

JAMF has had and has recently hired some incredibly talented former Casper admins that I'm sure would be sympathetic to this void.

Let's make Awesome-- Super Awesome !!!

SOLVED Posted: 6/27/14 at 3:30 PM by tjk

@donmontalvo careful with that "ring fencing" Jared might kick off again :p

SOLVED Posted: 6/27/14 at 3:45 PM by donmontalvo

@dpertschi Agreed, breakout sessions with JAMF would be awesome! Too much to discuss in just one sitting. I went ahead and posted a link to this thread over at the Feature Request link you provided (I voted that one up a while back).

@tkimpton Hushhhhh!!!!! :)

SOLVED Posted: 6/28/14 at 9:11 PM by donmontalvo

A few people pinged me to say my "Mark As Answer" is showing up as "Solved", so I'm undoing them. I submitted a feature request for a "Helpful Response" button.

Can we get a "Helpful Response" button on JAMF Nation?

Keep the responses coming, thanks!


SOLVED Posted: 6/29/14 at 12:06 AM by nate_walck

A few thoughts on this topic:

  1. Casper Suite doesn't need to actually use munki, just borrow some ideas.

Munki is great, but as many before have already discovered, it doesn't just bolt on to Casper Suite in a coherent fashion (nor should we expect it to). I don't think that this is the way forward. Munki was made to be controlled via flat files on a web server. It was not created with the intention to use a Web UI or Cocoa app to configure it (Although the community has made great examples of both applications).

Instead, take some of the ideas that are implemented in munki and use them in a context that makes sense (and is easy to use) within a Web Interface. For instance, make sure all clients have the newest Firefox that exists in the repo (also scoped to Production, Testing, etc) and you would have the best of both worlds: A GUI-based admin experience AND an engine that figures stuff out client-side so the admin can get back to doing more important work.

I've used Casper Suite at two different employers for managing OS X and it always went like this:

\- Get excited because the Web UI can do a lot of sweet stuff with smart groups, scoping, etc
\- Dig into the software install mechanisms and start having the feeling that it may require more work than you had hoped
\- Go back to using Munki because I could get the same software-related tasks done with less time/energy

I would love to see Casper Suite's software installs overtake munki. I think the product would be unbeatable (open source or not) if the software install engine was modernized. If I could get amazing OS X and iOS management with a similar interface, how could I say no? It is a no brainer.

  1. Make it modular

While we are discussing the great web interface, lets dig deeper. If you have a large environment of Macs, you will be writing a good amount of code to make it all work(it really doesn't matter which tool you use, companies want stuff to work in odd ways). Building modularity into Casper Suite would be a *huge* plus to organizations of any size, not just the big ones.

Picture this: Your company specializes in web apps written in Ruby \+ Rails. If you could write a gem module for Casper suite and scope gem installs just like you do any other install (and report on them!), you would be beside yourself with joy. Then, you could put that module up for anyone else to use and they could have the same benefits.

The community would step up and write modules for all types of things if modules were an option (Python modules, Ruby gems, brew installs, etc). This is a huge piece of Puppet's success in my opinion...just look at the Puppet Forge (, you can find almost anything you want there (Linux-wise). This would allow you to "support" anything so long as it followed to a pre-determined format. Not every environment is the same and Macs are being used for more and more things, unlike the past (It isn't just creatives anymore) The only limit is of the admin creating the module.

The JAMF Nation has a history of sharing scripts, management strategies and helping each other out. If they can be given more powerful methods for building out and customizing the Casper Suite experience, there would be little reason to use anything else for managing OS X.

SOLVED Posted: 6/30/14 at 7:40 AM by donmontalvo

Related to this thread, we submitted a Feature Request for JSS to track package-id and version:

Please make JSS track "package-id" and "version" in package receipts

SOLVED Posted: 7/1/14 at 7:19 AM by Chris_Hafner

JNUC roundtable would be awesome. If it happens I'll be watching closely!

SOLVED Posted: 7/1/14 at 11:39 PM by loceee
Munki is great, but as many before have already discovered, it doesn't just bolt on to Casper Suite in a coherent fashion (nor should we expect it to). I don't think that this is the way forward. Munki was made to be controlled via flat files on a web server. It was not created with the intention to use a Web UI or Cocoa app to configure it (Although the community has made great examples of both applications).

I agree with this, they are very different beasts.. however the more I think about it I do believe it may be possible to sync the tools. I am only spitballing this but... by using only a small subset of munki, some integration could be possible. JAMF could piggyback on the great work and leverage the client and installation smarts. This would get us what want quicker.

Here are my parallel terminologies (it's assumed you have used munki)

  • computer configurations = mainfests \- (JAMF need also to extend these and make "pkg groups" that are nestable, pretty achievable)
  • categories = catalogs \- (or better \- make a staging field)

And assuming that the JSS api exposed this stuff, potentially we could have a munki-syncer that read and generate a munki repo (it would be a sub directory on your Casper repo). Might need to hack munkiimport a little for paths (?)... but end result could be a pkg group like this:


  • MSOffice2011-14.3.6 \- cat: production
  • MSOffice2011-14.4.1 \- cat: beta
  • MSOffice2011-14.4.3 \- cat: dev

Instead of creating your usual smart groups and policies to deploy said software, you'd pull your pkg into Casper admin, drop it in the the Office group (which is nested inside: GeneralApps (pkggroup) / CreativeDept (computer cfg)). Then assign it to the beta staging category. Macs tagged as beta would get it installed. Job done.

From an admin standpoint munki's terminology would be obscured. The changes and extensions to Casper wouldn't be massive either. Thoughts?

SOLVED Posted: 7/9/14 at 2:22 PM by taugust04

I agree on the most part with all the posts made here so far. However, I also think that elements of the Managed Software Updates app on the Munki client should be integrated into Self Service without requiring there be a lot of configuration or tweaking on the back-end. I really like the idea of Self Service opening automatically to present a list of available updates that can be installed at the user's convenience before I force them down for compliance.

SOLVED Posted: 7/9/14 at 4:44 PM by clifhirtle

I would agree software update patching is the achilles heel of Casper.

90% of the software update process I implemented in our organization was gleaned from hacking together elements of @acdesigntech's and others jamfhelper scripts at the jamfhelper thread (, but often I do feel (as others) that there should not be as much custom scripting needed to get a basic multi-tiered patch methodology implemented.

That said, I do not see a ton of legwork in getting new updates pushed out to our users since this was setup, but we are approaching this in a bit simpler framework than most:

  • Weekly check \+ install of non-boot OS updates, prompt 3x for reboot then force others
  • 1 primary SoftwareUpdate policy per application, runs ongoing, scoped to smart group of XYZ version or below, and called by custom trigger only.
  • Custom trigger initiated by policies setup for each phase of an application's deployment. These do little more than run 1x, scope to phase groups, & fire the trigger to call the primary SWUpdate policy for each specific application updater

In this scenario, deploying a new update equals:

  1. Update smart group criteria for latest application version
  2. Swap PKG called by the primary SoftwareUpdate policy for that application
  3. Duplicate (or reset logs) \+ update policy activation date on existing custom trigger policies calling the primary SW policy

In this model, I find myself getting bogged down more with the logistics of software auditing/compliance than logistics of ongoing updates.

Additionally, each successive Apple OS moves closer to automatic security and application updates on by default. Are we looking at a future different than our existing, micro-managed SW versioning methodology we engage currently in our respective engineering roles? Not saying I know, but question's crossed my mind: am I solving a problem that's obsolete in 1-2 years?

At minimum, scripts like Rich's Flash auto-updater ( mean I do not waste much time managing Flash update anymore.

SOLVED Posted: 7/23/14 at 8:00 PM by lashomb

I'm going through my CCA this week and brought this up today. I started with Casper after the JNUC last year (I did attend though). I had Munki before and still use it, especially combined with AutoPkg, it's awesome.

I hope to see some real attention by JAMF at this years JNUC as well.

SOLVED Posted: 8/6/14 at 1:28 PM by yr_joelbruner

So I'd had a feature suggestion a while back:
Recon/JSS: Collect Package Receipt versions and treat as its own data type

It's "Under Review" -- the data type seems to be a no go and somewhat understandable given that the CFBundleShortVersionString has no enforced format and could be arbitrary data. Chucking that aside, simply collecting package receipts would be a great help. I use dummy package receipts to get machines into Smart Groups which then policies scope to in order to push out updates and/or 1st installs. As mentioned above making new EAs was getting a bit onerous, but the "devil you know".

We are moving our Macs to a global v9 JSS server and using Sites to partition the Macs of each operating company. Unfortunately Sites separates some things (Policies, Computer Object) but not others (Scripts, Packages, Extension Attributes). Naming conventions can work around Packages and Scripts, but shared Extension Attributes world-wide across thousands of Macs is not ideal so we are trying to use those as little as possible.

With not being able to use Extension Attributes for getting Package receipts versions (/var/db/receipts). I had the idea to make dummy Apps to be inventoried that would be named after a receipt and be versioned with the receipt's PackageVersion. They are hidden in /Applications/Utilities/Receipts and get picked up with a good old jamf recon

Receipts with .app appended can then be can referenced in Applications Title (has/does not have) and Application version (is, is not, like, not like) criteria in the Software Information category

Not really a long term solution but might help someone now or spur some more discussion :)

Pseudo App Receipts

[ -f /tmp/debug ] && set -x

if [ ! -d /Applications/Utilities/Receipts ]; then
mkdir -p -m 775 /Applications/Utilities/Receipts
chflags hidden /Applications/Utilities/Receipts

IFS=$'\t\n\r' #oh Adobe Connect did you really need to put spaces in your receipt's filemame?
for receipt in $(ls -1 /var/db/receipts/*plist); do
    #PlistBuddy is preferable to defaults because defaults will start returning nulls after many requests in rapid succession which this script causes
    PackageVersion=$(/usr/libexec/PlistBuddy -c "Print :PackageVersion" $receipt)
    [ -z "$PackageVersion" ] && continue; # if blank skip to the next file

    PackageIdentifier=$(/usr/libexec/PlistBuddy -c "Print :PackageIdentifier" $receipt)
    [ -z "$PackageIdentifier" ] && continue; # if blank skip to the next file

    #recon looks for a MacOS folder, make it
    mkdir -p /Applications/Utilities/Receipts/$
    #write CFBundleShortVersionString to Info.plist
    defaults write /Applications/Utilities/Receipts/$ CFBundleShortVersionString -string "$PackageVersion"

#because root is the creator and defaults makes Info.plists with mode 700 perms, let's be nice and allow Finder to take a peak too
chmod -R 755 /Applications/Utilities/Receipts
chown -R administrator:staff /Applications/Utilities/Receipts
SOLVED Posted: 8/13/14 at 12:22 PM by dvasquez

colonel panic thank you for that break down. I use JAMF Helper to notify and also to direct users to self service. I am very interested in your process. More than that though better software update and patch management would be a sweet addition to Casper. I am going to look into AutoPkg more in the coming weeks. Thanks for sharing.

SOLVED Posted: 10/2/14 at 5:19 PM by donmontalvo

I have my fingers crossed that we'll hear some good news at JNUC 2014. :)

SOLVED Posted: 10/2/14 at 5:21 PM by scottb

@donmontalvo \- sounds like insider trading on your part! I would love to hear of such things...

SOLVED Posted: 10/2/14 at 5:55 PM by loceee

@yr_joelbruner \- I missed this post, pretty interesting idea! You could also store the receipts in more hidden location and just add that to your application search scope.. in Settings / Computer Management / Inventory Collection ...

It's got me thinking... thanks!

SOLVED Posted: 10/2/14 at 6:42 PM by elliotjordan

Would love to see you all at my JNUC2014 session. :-)

SOLVED Posted: 10/2/14 at 7:06 PM by donmontalvo

@boettchs I wish I did know what's coming in JSS 10. :)

SOLVED Posted: 10/6/14 at 5:22 PM by ChrisL

@elliotjordan][/url \- looking forward to it!

I hope to see folks at mine also

The JSS Gem I'm presenting will be opensourced, and is the precursor to opensourcing 'd3', another pkg deployment system I presented at JNUC 2012. I had to wait for approval to announce that!

SOLVED Posted: 10/21/14 at 10:53 AM by donmontalvo

Thank you JAMF!

external image link

SOLVED Posted: 10/21/14 at 1:07 PM by mikedodge04

@donmontalvo what was announced in regards to Patch management ?

SOLVED Posted: 10/21/14 at 1:10 PM by brandonusher

@mikedodge04 Patch Management would be another section under "Computers". It would pull all the up to date information from and check it against all computers known to the JSS. Once it calculates who needs the new version, it would then take whatever action you want. You can choose install via Self-Service or automated install in the background like other policies, or according to them you could do both. Provide it in Self-Service and if it's still not installed by X date force the update.

SOLVED Posted: 10/21/14 at 1:18 PM by donmontalvo

I like the part about never having to download and package stuff. ;)

SOLVED Posted: 10/21/14 at 1:21 PM by spotter

I echo @donmontalvo... this is greatness!!!

Thanks JAMF... #JNUC

SOLVED Posted: 10/21/14 at 1:23 PM by CasperSally

Maybe my first ever implemented feature request?

It will be nice to finally get what several PC management products have offered for years.

Looking forward to seeing it implemented. Thanks for posting, @donmontalvo.

SOLVED Posted: 10/21/14 at 2:49 PM by benducklow

Loving the announcement of the Patch Mgmt feature to come. My only (major) concern would be the source of the patches due to legal/HIPPA compliance concerns. I couldn't imagine JN would be the source for the actual package... Regardless, I will be eagerly anticipating the technical aspect of the great feature!

SOLVED Posted: 10/21/14 at 3:05 PM by mm2270

From the little bit I got from it, JAMF will be using the download locations (URLs) posted for each 3rd party software item already in JAMFNations 3rd party section to know where to download it from. It's actually very similar to something I've been working on myself. The main difference was that I am not using JAMFNation as a source, but only because I couldn't actually figure out how to do that reliably.

In any event, this new feature will be a game changer for many of us. I don't know that it will be a perfect fit for all environments, nor will it likely work for every single app you may need to keep up to date, but even if it only works for all the major products, it will handle 90%+ of the now manual patching we need to do. And I love that this won't even require complex Smart Groups to work! Pure brilliance!

SOLVED Posted: 10/21/14 at 3:19 PM by RobertHammen

I have lots of questions on how this will work. In larger corporate environments I need to scope the updates to a static group first, and let some period of time (1-2 weeks) pass before deployment to everyone who needs it...

SOLVED Posted: 10/21/14 at 3:58 PM by emily

I wonder if this would apply to Apple software updates in addition to third-party apps?

SOLVED Posted: 10/21/14 at 4:02 PM by donmontalvo

NetSUS/AppleSUS should handle this.

SOLVED Posted: 10/21/14 at 4:07 PM by bpavlov

This sounds very interesting and exciting. However, I hope there's more to it than what they stated because right now it sounds like it depends on JAMF Nation to get update links and then it deploys to all computers. That definitely won't work for all environments. 2 major problems I see with that right off the bat:

  1. Admins should get the ability to deploy their own customized updates because some vendors have horrible packages that sometimes need to be modified.
  2. Admins should be able to deploy the patch to one, many or all computers based on whatever groups they configure in the JSS.

Let me reiterate that it is very exciting to hear this news. It's kind of like rolling some of the features of Munki and AutoPkg into one. The ability to update out-of-date applications based on the app version the computer is running (Munki) while also automating how it checks/downloads updates (AutoPkg).

I just hope when it gets deployed that it's fully featured and not something that is limited in how it can be customized.

SOLVED Posted: 10/21/14 at 4:13 PM by mm2270

From what was presented, it does not auto deploy to all computers. You set up each individual software title individually and for each one you set up, have the option of choosing between just placing the update in Self Service or deploying it silently.

The preview at JNUC was only a brief overview. There is definitely more to come on this so we'll just need to be patient. But what we saw looked pretty awesome.

SOLVED Posted: 10/21/14 at 8:24 PM by loceee

Watching with interest (and continuing secret work on Patchoo2 \- let's just say I am planning on eliminating many of those yicky smart groups and wonky version checks).

I am hoping they have some sort of software testing track implementation. It's invaluable to have dev / beta / production client groups.

But I also will just be happy to something simple that will save many hours of wasted time for the majority of Casper admins!

Life's too short to be packaging.

SOLVED Posted: 10/22/14 at 9:44 AM by donmontalvo

I agree! The concept of staged deployment is built into @gregneagle's Munki tool. New/updated apps or patches need to be vetted before deployment. Automatic downloading/packaging/importing into JSS is awesome, hopefully staging will be included in JSS n.

SOLVED Posted: 10/22/14 at 10:28 AM by mscottblake

Yeah, that's my number one request. The munki catalogs are a great idea. So great that I was trying to come up with a best of both worlds approach for my environment. I'm very interested in how the patch management gets implemented.

SOLVED Posted: 10/22/14 at 10:58 PM by elliotjordan

As JNUC attendees may have seen at my session this afternoon, AutoPkgr now supports direct JSS integration, and can be extended to completely automate the Mac app patching process (although you may want to proceed with caution).

There's a discussion open here, for those who are interested:

I'm hoping other Casper admins find this as useful as we have. We're looking forward to seeing what JAMF introduces, but until then AutoPkgr is your friend.

SOLVED Posted: 11/13/14 at 12:28 PM by donmontalvo


Please make JSS track "package-id" and "version" in package receipts

SOLVED Posted: 1/20/15 at 9:27 PM by donmontalvo

In the interest of keeping this thread alive, here is another tidbit from the ##osx-server IRC channel.

Scroll to around 09:12:

@gneagle: Yet another example of a basic task that should be simple, but isn't: @adamcodega: I don't know why people are even bothering trying to update apps with Casper right now. @gneagle: adamcodega: Because that's the tool they bought and they expect to be able to use it @adamcodega: Well, now they know.

@gregneagle will probably rag on me for picking up on "fumes from a previous conversation"...but he has some very valid points.

Just a reminder to take a moment to watch the relevant part of last October's JNUC2014 keynote address.

This link takes you to that point in the video. Enjoy!

SOLVED Posted: 1/21/15 at 2:48 AM by daz_wallace

I heard this was shown at JNUC2014. +1 / #WANT

SOLVED Posted: 1/21/15 at 9:34 AM by davidacland

I'm definitely looking forward to this being added. I'm assuming it will be before Oct this year otherwise JAMF may get some criticism.

It doesn't look like an easy thing to add in, considering the number of possible variables with every update. Just hoping it will be smooth enough to use when it is released!

SOLVED Posted: 1/21/15 at 9:47 AM by mm2270

The only concern I have about what was shown is that it was mentioned JAMF would be using the Third Party Applications information from JAMFNation to determine versions and download locations. If that's the case, they will probably need to control that information. Right now, anyone can go in and edit the information in the 3rd party section for any product. Allowing anyone here to edit it could potentially mean breaking everyone's patch management solution. So JAMF will either need to have specific fields in each entry they lock down and have control over, or just not allow anyone to edit those entries anymore.
It will also mean its on JAMF to continuously stay on top of and keep those entries as accurate as possible. That's kind of a tall order unless they are working on some pretty advanced process to automate that.

All in all, I look forward to what they are putting together. Until then, we'll use our custom processes, since the current process of Smart Groups and manual packages is tedious. AutoPkg and AutoPkgr help alleviate this somewhat, but some organizations aren't inclined to plug in an external product for this and would rather use what's built in to the product they purchased. Even if its not perfect, my guess is JAMF's patch management solution will have a pretty good uptake by customers.

SOLVED Posted: 1/22/15 at 8:30 AM by Chris_Hafner

One of the other things that JAMF was very clear to point out was that they recognize the need to focus on quality control (for lack of a better term) as opposed to fast feature roll out. A lot of folks went through a lot of issues with the transition in early 9.x, myself included. Trust me, I want it. I want it bad. However, when I do get my hands on JAMFs version of patch management I want the darned thing to work or I don't want it at all!

I'm really happy that JAMF announced the fact that they are working on it. Personally, I'm not ready to move toward AutoPKGr even though I know it works. It's too much outlay and thumb holding for my organization (I'm Casper Admin \+ a million other things). Personally, I'm willing to hold off for as long as necessary to get something I can trust, that will also make my job easier.

SOLVED Posted: 1/22/15 at 8:43 AM by dvasquez

I agree. I hope that it works and that implementation can be a little more straight forward. I have had all kinds of issues implementing things (early on) that I really wanted to use that would in theory increase our productivity. I am also excited about this new tool. Yes please more QA and testing before a quick software release. Chris_Hafner I get what your saying about work loads as I am in a similar situation. I am totally ok with working to implement something new that does not require more hand holding.

SOLVED Posted: 1/22/15 at 8:51 AM by CasperSally

I agree with @Chris_Hafner, even though I created the original patch management feature request (

Autopkg makes it so easy to get the latest files, it takes me \~10 minutes a month to update/stage policies without even trying to automate it with other tools that are out there. I'm fine with that at this point. Like Chris, I manage a million other things outside of Casper, and just want something that is quick and reliable.

I want patch management built in to the product, but I also don't want it at the expense of support being stretched too thin. Since moving over to config profiles and relying on cert based communication, something breaks with each upgrade for us that takes weeks+ to resolve. Apple's yearly upgrade cycle forces us to upgrade JSS 1-2x a year just to support the latest OS (and iOS).

The thought of JAMF taking on something else big and seemingly complicated scares me. Hopefully I'm underestimating the size and resources of the dev/support team.

SOLVED Posted: 1/22/15 at 10:00 AM by donmontalvo

I doubt (or hope) the patch management feature(s) won't rely on community manifests \- we really need the ability to create/manage our own manifests internally (for risk mitigation, security, confidentiality, etc., reasons).

I'd love to see a followup communication from JAMF on where they are, what path they are heading down, even if is fuzzy/vague enough to protect themselves from being derailed (always a risk when too many conductors are trying to drive a train).

Planning my trip to JNUC2015... :)


SOLVED Posted: 1/28/15 at 12:18 PM by lashomb

I'd rather have community sourced manifests than JAMF sourced ones to be honest. Just look at Licensed Software definitions and how fast those go out of date. AutoPkg is a perfect example of how effective and quick community-sourced "recipes" can be.

As for security, my only concern is that the source of the software is from the vendor and not a third-party, after that, it doesn't matter how I get it. If I have an application that I don't want to share my specific recipes for, no one is forcing me to do so.

SOLVED Posted: 1/28/15 at 3:39 PM by donmontalvo

@lashomb I think a good compromise would be to give us the option to choose. Create our own, or link to community provided manifests. Everyone would be happy. :)

SOLVED Posted: 1/28/15 at 3:43 PM by lashomb

@donmontalvo As long as it has something easy like autopkg repo-sync, which will pull down the latest recipes from your added repos from github. We don't need to go backwards now that the Mac Admin community has excellent tools like this available.

SOLVED Posted: 1/28/15 at 5:36 PM by donmontalvo

@lashomb yep, and that's why it is important to keep this thread alive. JAMF are monitoring this thread, the more feedback they get on how these methodologies can help make the lives of Mac admins better, the better. :)

SOLVED Posted: 3/20/15 at 3:48 PM by sirkyle

Something I have noticed missing from this thread is built-in "blocking application" support for policies. Is seems a bit ridiculous to have to script this for each application deployment. I suggest the developers at JAMF review how Munki addresses this issue. Out of all the feature request, little things like this save huge amounts of time and will make the product more palatable to admins regardless of the level of skill.

SOLVED Posted: 4/13/15 at 11:38 AM by dvasquez

Let's hope!!

Do it!

SOLVED Posted: 4/13/15 at 1:55 PM by donmontalvo

If JSS 10 can allow import of profiles, for delivery as we deliver PKGs/DMGs that would be helpful for environments that have proxy servers.

SOLVED Posted: 9/8/15 at 8:54 PM by donmontalvo

As we approach JNUC2015, good to keep this thread fresh.

Interesting and sometimes funny responses to a Feature Request:

Smart computer group application version compare with greater than & less than

SOLVED Posted: 10/9/15 at 6:43 PM by donmontalvo

@CasperSally fingers crossed your Feature Request finally comes to fruition...

Patch Management Integration

SOLVED Posted: 10/9/15 at 9:23 PM by dpertschi

The 2014 teaser is, well, a year + in the making. I'm desperately hoping something substantial is announced on this next week.

SOLVED Posted: 10/9/15 at 10:36 PM by mm2270

I'll be watching this thread with interest come next week. I do expect there to be an announcement around this, since it was shown off a bit last year. If its not announced that its release is imminent, well, there will be some 'splaining to do I reckon.

SOLVED Posted: 10/10/15 at 2:26 AM by davidacland

My guess would be that it'll get mentioned but not sure if it's anywhere near ready.

I've started using the autopkg / JSS importer method but would personally still like something more integrated from JAMF.

SOLVED Posted: 10/10/15 at 11:01 AM by emily

Saying it was "shown off a bit" is pretty generous; at the marketing event we didn't even get any screenshots, just general conversation about the effort to make it. I wouldn't be surprised if we maybe get some screenshots and general concept but not much more.

/me is setting low expectations to not be disappointed

SOLVED Posted: 10/10/15 at 10:14 PM by mm2270

@emilykausalik It sounds like you're referring to JAMF's Ice Out event, yes? If so, then yeah, there was not even a mention of the patch management solution from what I recall.
But I was referring to what was actually shown at JNUC 2014 during the first day keynote. It was more than just a mention or a bullet point. There was some type of demo of it in action. Now, granted, it probably was just a canned demo or concept recording or something, not sure, but still, it got some actual screen time.

This was about a year ago, and in those intervening months, we've heard nary a peep about this. That's a little concerning. I'm sure 10.11 may have derailed some of the development this year on it since JAMF needed to work to make their existing product compatible with it. Still, a year is a while, so I'm a bit surprised there's been no talk of it, no beta versions with early builds of it in place, etc. Its been very quiet.
I won't be there next week to see anything, but I'm hoping it gets brought up again at least. I don't think everyone that was there then, who will be there now, will just forget JAMF talked about it last year.

SOLVED Posted: 10/12/15 at 6:59 AM by CasperSally

@mm2270 - The Ice Out Event - don't bring back the bad memories!

I'm sure they'll mention patch at JNUC, and I'll be following along the news for sure. I'm not expecting production release of patch soon, but probably some beta release in a month or so? Totally conjecture, but I know more support JAMFers were moved to the Patch team in recent weeks/months.

While I requested
3rd party patch management back in 2012 (!!!) I'm quite happy with our Autopkgr implementation. The only place my patching could be a smoother would be the promotion from test to production, but I haven't implemented the new launch daemon approach yet - awaiting to see what JAMF will announce this week.

Honestly, I am more worried about support getting stretched more thin at this point than I am at finally getting Patch now. I've had some lingering JSS issues I'd really like to see finally resolved.

SOLVED Posted: 10/13/15 at 10:27 AM by donmontalvo

"Quality first, Patch Management in the works but will be released when ready." - JAMF CEO

Music to my/our ears.

SOLVED Posted: 10/13/15 at 10:41 AM by Aziz

@donmontalvo And I have no problem with that. I'd rather have something be great and working day one instead of being rushed and broken. Also, Dean is a pretty cool CEO.

SOLVED Posted: 10/13/15 at 10:47 AM by donmontalvo

Agreed, it is great to hear the JAMF CEO tell the JAMF community that Patch Management is coming, it is taken very seriously, and that quality is #1. Everyone wins. :)

SOLVED Posted: 10/13/15 at 10:52 AM by jgwatson

Was there a timeframe? Why preview it 1 year ago if it's going to take forever to complete? Are we talking months, years?

SOLVED Posted: 10/13/15 at 10:52 AM by mm2270

Sounds good! Glad it was brought up and is still a goal for the company.
I hope to see some Casper Suite beta builds incorporating it sometime next year.

SOLVED Posted: 10/13/15 at 11:00 AM by Chris_Hafner

They mentioned ~<6 months... I think (hard of hearing here). But promised regular updates. Regardless, I am happy that it's still a big priority.

SOLVED Posted: 10/13/15 at 11:22 AM

Really liked Dean's portion of the keynote. Stability first, thanks.

EDIT: Which is not to say I didn't enjoy the rest of it.

SOLVED Posted: 2/16/16 at 5:44 PM by localhorst

The Mac team at Oxford devoted early 2015 a bit of time to develop our own solution. Our goal was to remove the software deployment and updates entirely from the Casper Suite and facilitate a more advanced autopkg + Munki workflow.

As a result we built a bit of middleware (aka glue) to enable inventory information in the JSS to be used to manage Munki clients. Our solution integrates nicely with all tools of the Munki ecosystem: one can use autopkg, MunkiAdmin, MunkiWebAdmin, munki-staging, and all the other great Open Source software out there.

The code is in production in our environment since mid 2015. We are actively maintaining the code, but our focus are still features. So please forgive us not having spent time on a nice UI. Currently one has to rely on the code generated Django admin interface.

There is also an initial draft of some set-up instructions and to get a bit of an idea how it all works have a look at the slides of my presentation at MacADUK.

I find it important to highlight that this is not a solution for the part-time admin. Migrating all software packages from the JSS to autopkg+Munki takes a bit of time. However, the gained amount of automation dramatically reduces the error rate and potentially frees up resource for other enjoyable development work.

We would be interested in feedback and comments. Bug reports and pull requests are obviously also more than welcome.

SOLVED Posted: 2/16/16 at 7:41 PM by loceee

@localhorst Boom! Wow!

SOLVED Posted: 2/17/16 at 4:58 PM by calumhunter


Why isn't JAMF, a multi million dollar company, with a number of talented engineers able to do this?

SOLVED Posted: 2/17/16 at 5:12 PM by gachowski


I would assume many reasons, all of which I am guessing are valid.. As you said JAMF has talented engineers, and I for one am going to give them the benefit of doubt that they are doing their best to solve the issue the best they can.


SOLVED Posted: 2/17/16 at 5:18 PM by gachowski

I would also like to point out that, this is no longer the right way to manage software on Mac OS X...

With VPP device-based app assignment, we should force our software vendors to use the apps store. If it's not in the store and the vendor won't supply a VPP code then it shouldn't be on the Mac, or in your build.

Apple and it's MDM vendors have built/are building a software delivery and update infrastructure that will be many time more robust than anything we alone can build.


SOLVED Posted: 2/17/16 at 5:26 PM by nessts

I agree with @gachowski to a point, however, Office 2016, SEP, Firefox, Flash, Java, Chrome, Silverlight, and I am sure the list could go on for many many more lines of things that many of my customers have to have in order to work are still not there. And lets not even start on how painful registering for VPP and DEP are in very large organizations. While its likely the future, its one that is not awfully close would be my best guess, at least until Apple closes the door on OS X merges it with iOS or limits it to the point that iOS is and then will it really matter?

SOLVED Posted: 2/17/16 at 5:26 PM by seanbalsiger

@calumhunter Has anyone from JAMF said they CAN'T do this?

Their CEO said they ARE doing it and that they won't release until it's ready. Seems like it's probably just not at the quality level they require and/or they are just waiting until 10 is finished to drop it with that.

SOLVED Posted: 2/17/16 at 5:31 PM by seanbalsiger


If it's not in the store and the vendor won't supply a VPP code then it shouldn't be on the Mac, or in your build.

I have to disagree. We use plenty of software that's not available in the app store and I am perfectly fine with developers not wanting to fork over 30% to Apple or be limited by restrictions imposed on apps that are available there.

SOLVED Posted: 2/17/16 at 5:35 PM by gachowski


I am hounding MS at the lower levels, there is no reason that the can't provide VPP for office : ) : )


SOLVED Posted: 2/17/16 at 5:38 PM by kstrick

I'm thinking we will see a more "Munki" like patching solution with Casper/JSS version 10

SOLVED Posted: 2/17/16 at 5:51 PM by gachowski


Just to push back a little : ) I think if you look far enough down the road and I am thinking two years..... software not following restrictions imposed on apps in the apps store are going to be consider a security risk.

: )


PS I am also about 50% sure that you can do B2B apps and Apple won't take 30% but I couldn't find any documentation on that..

PSS We should be pushing Apple to about that 30% if that is a road block for the developer.

SOLVED Posted: 2/17/16 at 6:04 PM by seanbalsiger


I think if you look far enough down the road and I am thinking two years..... software not following restrictions imposed on apps in the apps store are going to be consider a security risk.

I can definitely see that being the case but there's a lot of apps that do cool stuff that violates Apple's policies. One example I can think of is Audio Hijack. It's a great little app that allows you to quickly and easily record audio from any app. The developer's website says they don't offer most of their apps in the app store because they violate Apple's policies. I'm still more than happy to take my chances and trust them because I find the app to be useful.

PSS We should be pushing Apple to about that 30% if that is a road block for the developer.

I'm fairly certain that's one of the major reasons large, established companies like Microsoft don't sell software on the App Store. They are more than happy to give away free software there but they will sell millions of copies of Office regardless of where it is available so why would they just give that money to Apple?

SOLVED Posted: 2/17/16 at 6:58 PM by calumhunter

@seanbalsiger I never said that JAMF said they can't do it. I asked the question why can't they do it. They have the engineering resources and the money, what's stopping them? A couple of guys at Oxford got it done in a few months JAMF first announced they were "working on it" in 2014
Theres been a feature request for better (any) patch management since 2012.
It's now 2016..... and still nothing from JAMF

@gachowski Lol been hanging out with Miles?
There are an untold number of pieces of software that need to be installed on machines that are not and will never be available in the App store. Just because YOUR environment doesn't use these titles or is able to get buy without them doesn't mean others are. Microsoft looks like its making the right moves to get onto the App Store. Thats great. But do you think Adobe are ever going to get there? Nope. They don't even use Apple PKG's! Atleast Office has been using PKG's for years.

To say that the only way to get software is through Apple' App store is crazy. Have a look at the AutoPKG recipes, there's hundreds of pieces of software that people use every day that is not available on the AppStore or admins wish to manage the version and update cycle of that software themselves. Do you know of a method to control the version of app updates via the MAS? How about a prod, pilot, dev branch style management of app updates? Or do you assume that every app update will be fine and won't break anything and thus no vetting of application updates is required. The old "if its on the store its good to go! attitude"

There are also a whole lot of environments where MDM and VPP can't work due to network configuration and corporate policies. Take the blinkers off, use some imagination. Think outside of your own environment.

As for MS not being able to provide VPP or office, actually yes there are a number of reasons that they are not on the App store yet. If you like, jump on to the Mac Admins slack and read up, Eric from MS (PM for Office) outlined the issues they currently have. They are working towards it but it is still a while away.

SOLVED Posted: 2/17/16 at 7:09 PM by donmontalvo

@calumhunter wrote:

There are an untold number of pieces of software that need to be installed on machines that are not and will never be available in the App store.

I'm sure Apple will keep clamping down on security. But it'll be some years before the long-in-tooth companies go out of business because they're too cheap to hire capable/competent coders to get their product(s) for the App Store.

SOLVED Posted: 2/17/16 at 7:51 PM by calumhunter

If you're that uptight about security and like the app store only model. Go get an iPad.
See how well you can do your job with it.

SOLVED Posted: 2/18/16 at 7:25 AM by CasperSally

Sketch left the panacea of the all mighty Apple App store for a reason, surely the 30% cut played into that.

Regardless, I agree it's disheartening my original feature request was from 2012 with virtually no (public) movement since. In that time, Autopkg made things much better for us admins. Autopkgr and JSSImporter improved on that...and now what the team at Oxford has done - with crickets from JAMF.

I am sure they regret announcing patch management in their 2014 JNUC. I'm glad it was mentioned by the CEO at JNUC 2015 that they're getting it right (surely they don't need a PR disaster if it is bug filled), but I sure hope we at least get a beta before 2016 JNUC.

Do I agree with the CEO that I want it done right? Sure... but my renewal to JAMF is not chump change... it's getting to be a harder pill to swallow as the months go on and open source is solving the problems my JAMF renewal isn't.

SOLVED Posted: 2/18/16 at 8:41 AM by bpavlov

@gachowski why would you talk in such absolutes? just because apple says one thing and prefers one thing does NOT mean that's the only way, should be the only way, and is the 'correct' way to do things. this extends beyond deploying software. anyone that thinks so needs to lay off the kool-aid. there are many ways to deploy software and depending on the environment there may be methods that are better suited based on the needs of the organization.

In fact I'm just going to quote someone else here:

@MrP wrote

I'm weary of anyone who declares absolutes in any scenario or rule. The precursor to these claims usually is something like "I can't think of why anyone would want/need..". The words never, always, phrase 'can't think of', etc show a lack of imagination more than anything.

@donmontalvo no one is going out of business because they refuse to join or drop out of the mac app store. unless apple suddenly decides that apps that aren't from the mac app store cannot run in which case you will most likely see 1) a lot of vendors look to make their products available on other platforms if they aren't already and/or 2) cripple their current software to work within the confines of the MAS policies.

@CasperSally Sketch left because they couldn't introduce the features they wanted while still following Apple MAS policy. I'm sure the 30% played a factor too, but it wasn't the only reason. make of that what you will.

As for JAMF, I suspect it maybe has gotten harder to implement feature requests and keeping up with the yearly OS releases for both OS X and iOS. Just look at 10.11 and iOS 9. It's taken from 9.80 to 9.82 to add support for most of the new features that Apple introduced with those OSes. And it makes sense that JAMF would focus on these as Apple is a big customer as well. Just sucks for the rest of us as we're left waiting for non-MDM/DEP related features to finally get introduced (patch management being one of many in a long list).

Anyways, I think the Oxford project is rather cool and is just one way to approach the issue. Why not have the best of both worlds? Use the best tool you can find for what you're trying to accomplish (or adapt it or make your own).

SOLVED Posted: 2/18/16 at 8:54 AM by dgreening

Count me in on the long list of folks waiting (and waiting) (and waiting) on non-MDM/DEP related features. And bug fixes...

I get that Apple/JAMF are trying to shore up their mostly EDU focused new features, as Google Chromebooks have kind of been eating Apple's lunch in the classroom. That being said, us non-EDU customers pay significantly more for JAMF licensing and have not really seen much in the way of new features. Some reporting and administration feature requests have been open for 4+ years without movement.

SOLVED Posted: 2/18/16 at 10:39 AM by seanbalsiger


I asked the question why can't they do it.

But they are doing it...why are you asking why they can't do something that they are doing?

A couple of guys at Oxford made it work in their environment in a couple months...that's a far cry from implementing a robust feature in JAMF that will work for (most) everyone.

SOLVED Posted: 2/18/16 at 11:30 AM by Chris_Hafner

Business case and all aside, I think it's important to recognize the fact that properly built and secured applications do and will exist completely separate from the MAS. So far as they've got a signed package and no big security holes, I'm A-OK with many types of distribution.

Now, I applaud the work of the various teams and individuals pushing this cause (patch management) forward. Here's to holding a beer in salute of friendly and functional patch management in all of our futures (Yes, the folks successfully using Autopkgr/Munki, etc can snicker). Yet this work will continue to push JAMF and other companies (hopefully Apple) to create robust, friendly and trustworthy solutions. It's the TRUST that I need. While I know that very serious effort and thought went into all of those aforementioned projects, I haven't put any of the existing solutions into production as they require quite a bit of supervision on my part and, because they do, the convenience simply never resolves for me.

@seanbalsiger has the right of it I think. Whatever JAMF put's out, it's going to be pounded not only by all of us, extra large enterprises like IBM/CISCO but by every tech that's gone through a jumpstart and just wants to set it and forget it. I'll agree though. Touting it in 2014 was probably a mistake. At least we know that they're working on it but the clock did start ticking at JAMFs own mention of the project. I do wish that we had a little more of a road map.

SOLVED Posted: 2/18/16 at 11:33 AM by nessts

I think Apple fans expecting a road map out of anybody else is quite humorous.

SOLVED Posted: 2/18/16 at 11:38 AM by Chris_Hafner

@nessts I'm not sure exactly what you mean here. Roadmaps are rather important when making long term purchasing decisions or investments. They're not written in stone of course, but they are quite useful.

SOLVED Posted: 2/18/16 at 11:43 AM by gachowski


I like absolutes, to prove my points : ) I'll go back to that thread that you quoted and quote myself because it's this is the same argument. Keep doing management/security the way it's always been done or move to improved ways...

I am interpreting what you are saying is that that "Organization with heavy hardening requirements" are better at securing the Mac OS than Apple. I think when you say it like that it super crazy... I am not saying Apple is right all the time, but they are better than most orgs. C PS For you sports fans.. it's skating to were the puck was in 1902 not were it is today or tomorrow...

The Mac admin community is full of people still trying to manage the Mac like Windows/the old way and is down right crazy. If you are happy just doing management/security the way it's always been done, that is fine but, I know that we need to push the community to do better.

As much as it sucks, most managers/CIO/CISO don't want to do anything out of the normal so unless we talk about change and and take the risks like Facebook, IBM and Apple push the envelope nothing will get better.

I would also like to point out that doing the same things as those very big and important companies is really not that much risk.


SOLVED Posted: 2/18/16 at 11:43 AM by nessts

Apple's closest thing to a road map is the newest most beautiful powerful yet, wonderful operating system will be available this fall. Good luck on getting any hardware road map out of them. Therefore, I find JAMF's patch management will be available when its ready to fit quite perfectly in the ecosystem. I just think more time is wasted discussing easier ways of doing patch management than it takes to do it personally.

SOLVED Posted: 2/18/16 at 12:04 PM by Chris_Hafner

Ahh... Apple 'roadmaps'. I see. I thought we were talking about anyone BUT Apple.

SOLVED Posted: 4/1/16 at 5:38 PM by ChrisL

Hi Everyone,

d3 has been released as open-source:

Happy Apple's 40th!

SOLVED Posted: 5/19/16 at 6:37 PM by donmontalvo
SOLVED Posted: 5/19/16 at 7:12 PM by calumhunter


SOLVED Posted: 5/19/16 at 9:53 PM by donmontalvo

SOLVED Posted: 7/21/16 at 10:01 AM by donmontalvo

JSS 9.93 steps...its all good. :)

SOLVED Posted: 8/2/16 at 10:01 AM by erin.miska

Just wanted to let you all know that as of the Casper Suite 9.93, we have added some initial patch functionality for 34 supported third-party titles. For each of these titles, you can get automated compliance reports, notifications for available updates, and easier patch scoping. (See Look for additional supported titles and expanded patch functionality in future releases.

SOLVED Posted: 8/2/16 at 10:04 AM by Chris_Hafner

YEA! Downloading now! What is "Infrastructure Manager" and how did I miss a new product?

SOLVED Posted: 8/2/16 at 10:44 AM by davidacland

Hey @erin.miska

Not sure if I'm looking in the wrong place but where can I see the list of the 34 supported titles?

SOLVED Posted: 8/2/16 at 10:47 AM by erin.miska

Hey @davidacland, check out the "Patch Reporting Software Titles" section of the 9.93 admin guide. It's largely Adobe titles, web browsers, Microsoft Office titles, Java titles, and a couple anti-virus titles. We based the list off of feedback from Casper Suite admins, and we're looking to continue getting that feedback as we expand the list!

SOLVED Posted: 8/2/16 at 10:49 AM by davidacland

Perfect, thanks :)

SOLVED Posted: 8/2/16 at 12:09 PM by donmontalvo

Looking forward to the OS X "greater than" and "less than" scoping criteria. #HappyDance

SOLVED Posted: 10/18/16 at 8:23 AM by donmontalvo

35 minutes before #JNUC2016

SOLVED Posted: 10/18/16 at 9:33 AM by CasperSally

@donmontalvo first half of 2017. yawn.

SOLVED Posted: 10/18/16 at 11:28 AM by pchen_plaid

Remember two years ago when they actually mentioned this?

SOLVED Posted: 10/18/16 at 11:33 AM by georgecm12

So, I guess I may as well go ahead and implement something "in the mean time."

Is Patchoo still in development?

SOLVED Posted: 10/18/16 at 11:35 AM by dvasquez

Excited about patch management policy.

Excited about version 10.

SOLVED Posted: 10/18/16 at 11:37 AM by mikedodge04


SOLVED Posted: 10/18/16 at 12:43 PM by iJake

@CasperSally Would you rather rush it or get it right? v10 is not just a reskinning of the console. They are rewriting the presentation framework to handle much larger datasets. Us larger customers have been complaining for quite a while that the current design does not scale. And it doesn't. They are taking the time to rewrite the UI to handle scale of tens of thousands of machines.

SOLVED Posted: 10/18/16 at 12:56 PM by dvasquez

Munki is good I have used the tools. I am more excited about how Jamf will implement and integrate.

Excited to see how it all plays out.

Scalability is key!

SOLVED Posted: 10/18/16 at 1:00 PM by donmontalvo

I'm actually quite happy Jamf (yee-amf? jam-eff?) decided to rewrite from the ground up, as there is 10+ years of legacy code under the hood. Fresh slate. Lots of foundation work to lay down before putting up walls and curtains.

"When I told my wife Jamf wanted to film us in bed, she was like 'Awesome!'" - Dean Hagar at #JNUC2016

SOLVED Posted: 10/18/16 at 1:20 PM by CasperSally

@iJake - C'mon, obviously, I'd rather them get it right. "Wouldn't you rather they get it right" was the same thing people said after JNUC 2015. My patch feature request goes back to July of 2012. Sorry for being disappointed we will be waiting another 3-8 months after requesting it 50+ months ago .

And if it's released more towards mid 2017 (May/June), we probably aren't the only school system who will be hard pressed to implement it before next Fall.

It is what it is. Luckily, Autopkgr exists and seems to work great for our environment. I'm thankful that Erin and the rest of the team are dedicated to make a good product, but I think it's fair to be disappointed on timeline, too, given the cost of the JAMF Pro suite.

SOLVED Posted: 10/18/16 at 1:27 PM by iJake

@CasperSally I should have been more clear that I meant I'm fairly certain the reengineering for scale has delayed patching not to mention they scrapped their original plan for it. You're definitely not wrong to be disappointed it has taken so long. I think the reporting could have been implemented long ago. We are mostly on the same page.

SOLVED Posted: 10/18/16 at 5:37 PM by loceee

@georgecm12 re: Patchoo, I am back in the land of macAdmins, so ...... maybe, but I kind of want it to be made irrelevant by jp10. We'll see I guess. Check out @franton repo for the most functional version. I have a few other priorities before I sink my teeth into my macs at newjob.