Managing Software Patches/Updates, Best Practices with Casper.

One thing you could consider is having policies assigned to computers to run once per computer, then when you have a patched version to apply, you modify the policy to include the update or new version and flush the history for that policy. It will then run again for each computer. I recently did this for Adobe Reader 10.1.2 and we're starting to do this for most of our policies.

The only catch is that if you want to ensure that this policy runs for reimaged computers, you need to flush policy history as part of the imaging process, which can be done with a script.

All of my Casper servers run on OS X Server, and all of them also run the SUS service. I have one main SUS and 5 that cascade from it. Then set up the SUS servers in the JSS and assign them by network segments. Then create a self service policy that users can trigger that installs all updates and forces a reboot.

For non Apple products I see if there is a PKG or MPKG and drop it into Casper Admin. Then create policies to install it. If I have to repackage the app for an update I usually update it and see if an overwrite does the trick, otherwise index the app, uninstall it first, then run the install after.

Thanks for your reply. I already have these policies to push out the updates set at running at once per computer. I think my main problem is that the newly imaged or re-imaged computers already are receiving some of these packages when they are imaged through a configuration in Casper Admin, and then again through the policy that runs on all the managed computers, so the download ends up getting duplicated.

Have it set once per a computer, and then when it reimages have it flush the logs for that computer so updates can be reapplied. For official Apple Updates, JAMF uses the software update binary that will check for current updates and only apply those you need. SUS can manage that by allowing you to set up what you need.

Tom,
Are you programmatically flushing a computers logs at re-imaging, or is that a manual process?

I like the sound of that, but not sure how I'd coordinate to do that with half a dozen techs around the country never knowing (or caring) when they reimage machines

thanks,
Darrin

So, I'm guessing that my best approach to non Apple SUS updates is to remove them from the Casper Imaging configurations and instead let them be applied by the policies I already have setup for computers that are already managed by the JSS?

I'm pretty happy with my current configuration of Apple updates. I have newly imaged machines download and install them automatically after imaging. Managed computers also download install Apple updates once a week, at login, and both policies seem to be working as I anticipated they would.

Yes, your best bet is to use the policies only and not have the software install through the configuration. We actually don't have any software install as part of the configuration. They're all assigned to the regular chceck-in trigger (everyHour in our case).

Our configurations have a script set to At Reboot that contains the command to flush the policy history (jamf flushPolicyHistory), update inventory (jamf recon) and to trigger the regular policy check-in (jamf policy -trigger everyHour).

I don't see why its better to have 'empty' configurations, otherwise what is the real point of Casper Admin?

Surely better to have base configurations, OS, Apps etc and the policies for updates?

Anyone gone down the reposado path for SUS?

I can see benefits both ways, with a config that is fully ready and with one that is OS only.

With a fully ready config you can compile the config and push in less than 10 minutes normally. That helps if you need to push out a lot of machines, or just need to get the base apps on your machines quickly. The down side to this is that if there is an update to an app, like Flash or Firefox, you are having to re-build your config and re-compile it, which takes time.

If you use the OS only config method, then any time there is an app update, you only have to update the policy that pushes that app and there is no re-compile time involved. This, to me, would be a true modular approach co imaging.

In the end, it all comes down to what works best for your environment. I've traditionally been one to use a config that contained all of my base apps, but I'm beginning to look more at thin imaging, applying just an OS and handling everything else with policies. I think this method gives me more flexibility in keeping the base apps updated.

Just my 2 pennies....

Steve

See what your saying here Steve and I can see some sense it that.

I run with a base software list, then smart folders off that with specific requirements, thus its pretty simple to update all my base software in one go.

The smart folders just contain an OS and maybe a major package like CS5

101 ways eh :)

I have an updated and compiled base OS as a parent config in CA
and stuff the rest of the apps in different Smart Configs.
If there is an app update I use the "replace in all configurations" option in CA to update my configs.
But as mentioned already, it totally depends on your environment and needs.

Anyone gone down the reposado path for SUS?

Yep, love it :)

sorry, this may be a thread hijack... Chris... Reposado.. anything I should look out for?

The docs on the GitHub page are actually pretty straight forward,
and http://groups.google.com/group/reposado helps a lot too.
I'm running it on Windows Server 2k8 with IIS.

I think I kind of worked this out on my own. I appreciate the feedback from everyone.

I found my biggest mistake was the criteria I was using for the Smart Groups. I was building the Smart Groups for deploying software updates by having it check to see if it had a pre-existing receipt from Casper that resides in /Library/Application Support/JAMF/Receipts. The policy was set to cache the software package if the most current version of the receipt (and in turn the software) wasn't installed.

The problem that was occurring is that on newly imaged computers, the Recon report wasn't being run and processed quickly enough for that inventory of receipts to be taken and compared to, before other policies were being triggered. So using the logic I was applying, the 'deploy cached update XYZ' policies would trigger because those receipts were not yet present in the JSS, even though they may have already been installed by Casper Imaging.

I've since corrected this by not using the receipts as a pre-requisite in the Smart Group, but instead, making sure it checks to see if the software and appropriate version is pre-installed. Since the Recon report isn't available, the opposite logic will apply, as it will not see that for example Firefox has been installed, so it will ignore the policy to update it at that time. Later on, once the inventory report has been run and processed by the JSS, the policy will check to see what version of the software is installed, and deploy the cached package, if required.

So Ted, the policy would be scoped to "has app 1.1" when deploying "app 1.2"?

Meaning "app 1.1" has to be found 1st before "app 1.2" is deployed?

my preferred method for enforcing app and os updates is to use munki and reposado. i'm in a casper shop right now, so casper handles app updates here. for most app updating, munki works better with minimal fuss. i find i have to monkey around (no pun intended) to get casper's tools to do what munki does out of the box for free.

setting up reposado is easy. if you aren't using it yet, please do so. it's more flexible than apple's sus and can be hosted anywhere with python and a web server installed.

Nate,

I'm a big fan of Munki. I use it along with DeployStudio at my part-time consulting position, which is a local state college with no funds. It works great, but I still prefer Casper.

Ben,

Yes that's sort of the idea. I'll use Firefox 9.0.1 as an example of what I'm doing.

I have a Smart Group that is built using the following criteria:

Smart Group Name: 'Update Firefox'
Membership Criteria: Application Title has Firefox
-and- Application Version not like 9.0.1
-and- Application Version not like 9.0.2
-and- Application Version not like 9.0.3
-and- Application Version not like 10.0
-and- Application Version not like 11.0

The extra version numbers are there so I don't 'step' on people running alphas and betas, and to give me some time to package up security releases. I could be more strict if I wanted. This criteria catches anyone with 9.0.0 and earlier to update.

I then create a 'Deploy Firefox' policy, to install cached, Firefox 9.0.1. The scope is the 'Update Firefox' smart group. The download is triggered by the every15 flag in the Casper. We already have policies on various groups of machines, that install any available cached packages at various triggers.

So far, so good. Still wondering if this is the best workflow...