Will JSS 10 finally bring us easy patch management?

[donmontalvo]

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: http://donmontalvo.com/jamf/jamfnation/IRC/valid-constructive-criticism-01.png
external image link
Direct link to the relevant feed: http://osx.michaellynn.org/freenode-osx-server/freenode-osx-server_2014-06-18.html

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!
https://jamfnation.jamfsoftware.com/discussion.html?id=10636

...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:

http://wiki.afp548.com/index.php/Main_Page

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

http://www.afp548.com/2013/02/06/a-field-guide-to-irc

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.

Thanks,
Don

[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. :)

[donmontalvo]

@boettchs Um, thanks, I think. :D

[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.

[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 - https://jamfnation.jamfsoftware.com/featureRequest.html?id=2261 ) 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 :)

[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.

[nessts]

tunic != tutu @boettchs

[yan1212]

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

[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:

#!/bin/sh

## Set a flag to check if there are any updates available
UpdatesAvailable="No"

## 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" https://JSS.company.com/JSSResource/computers/macaddress/$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>/
/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++ ))
do
    CheckUpdate=`echo "$JSSGroups" | grep "${NonSysCore[$i]}"`
    if [ "$CheckUpdate" != "" ]; then
        UpdatesAvailable="Yes"
    fi
done

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

One of the Core Software Version numbers EAs:

#!/bin/sh

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

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 Client.app       (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:

#!/bin/sh

########## 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" https://JSS.company.com/JSSResource/computers/macaddress/$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>/
/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++ ))
do
    CheckUpdate=`echo "$JSSGroups" | grep "${NonSysCore[$i]}"`
    if [ "$CheckUpdate" != "" ]; then
        jamf policy -trigger "${NonSysCore[$i]}"
    fi
done

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 :(

[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.

[mcrispin]

so... tutu or not?

[donmontalvo]

@mcrispin][/url Um...no. :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...

https://www.youtube.com/watch?v=EOar7toRw80

[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: http://grahamgilbert.com/blog/2013/01/13/casper-vs-munki/

"... 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.

[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...

https://jamfnation.jamfsoftware.com/featureRequest.html?id=662

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 !!!

[tkimpton]

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

[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!!!!! :)

[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?
https://jamfnation.jamfsoftware.com/featureRequest.html?id=2364

Keep the responses coming, thanks!

Don

[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 (forge.puppetlabs.com), 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.

[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
https://jamfnation.jamfsoftware.com/featureRequest.html?id=2367

[Chris_Hafner]

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

[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

• 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?

[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.

[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 (https://jamfnation.jamfsoftware.com/discussion.html?id=5404), 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 (https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/install_latest_adobe_flash...) mean I do not waste much time managing Flash update anymore.

[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.

[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
https://jamfnation.jamfsoftware.com/featureRequest.html?id=396

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

#!/bin/bash
[ -f /tmp/debug ] && set -x

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

IFS=$'	

' #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/$PackageIdentifier.app/Contents/MacOS
    #write CFBundleShortVersionString to Info.plist
    defaults write /Applications/Utilities/Receipts/$PackageIdentifier.app/Contents/Info CFBundleShortVersionString -string "$PackageVersion"
done

#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

[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.

[donmontalvo]

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

[scottb]

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

[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!

[elliotjordan]

Would love to see you all at my JNUC2014 session. :-)
https://jamfnation.jamfsoftware.com/jnucEvent.html?eventId=109

[donmontalvo]

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

[ChrisL]

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

I hope to see folks at mine also https://jamfnation.jamfsoftware.com/jnucEvent.html?eventId=83

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!

[donmontalvo]

Thank you JAMF!

external image link

[mikedodge04]

@donmontalvo what was announced in regards to Patch management ?

[brandonusher]

@mikedodge04 Patch Management would be another section under "Computers". It would pull all the up to date information from JAMFNation.com 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.

[donmontalvo]

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

[spotter]

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

Thanks JAMF... #JNUC

[CasperSally]

Maybe my first ever implemented feature request? https://jamfnation.jamfsoftware.com/featureRequest.html?id=662

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.

[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!

[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!