Patch management through Casper

I would be very interested in the feedback as well.

Hasaan Herrington

Techincal Support II

Anchorage School District

As would I...

I use full blown SUS, but my SUS servers run 10.5.8 as do most my clients. I have 1 parent and 5 children SUS servers. Then I use casper to set the server and use self service to execute all updates. I have auto download and auto enable disabled. I found that if you do not disable them to begin with there is really no way to revert, guess that is a bug, or perhaps just some weird feature?

Now, for those of you that do not use SUS I would highly suggest at looking at the InstaUp2Date python scripts that come with InstaDMG. You will notice that Apple releases every patch as a full download and can be downloaded. If you look in the script that is actually what the script is doing. It is just pulling the file down from the URL where it is located and then using something like hdutil under the hood to slipstream the updates into an installer disk image.

You could manually download them and create a policy with them as they are typically PKGs, or MPKGS, or flat packages (DMGs), and Casper should be able to just push that out. The downside is that with out the SUS you are doing manual work here to download them and push them out, where as with a SUS you just sort of configure a few things and forget about it.

Not sure I understand the conversation here... If you are using SUS, you can keep 10.6.5 enabled and computers can update to that still. You just enforce that server as the update server and don’t enable 10.6.6 and don’t delete old updates on the SUS.

Then, in Casper, you manage the updates using policies... You have the granularity you need then without needing to store all of the SUS updates in your JSS Package Server storage.

--
John Wetter
Technical Services Manager
Educational Technology, Media & Information Services
Hopkins Public Schools
952-988-5373

The problem is that that doesn't work with this update because of what Apple did. The computers no longer see the 10.6.5 update at all.

This has always been something we've looked at, but can't quite figure out the timing.

For example, we want to update our 10.5.6 users to 10.5.8. We've got the policy worked out (trips the update via our SUS), but when should such a thing be triggered?

Since it requires a restart (and downtime for the user as it applies some of the updates) it gets tricky. If we do an every15 type thing, it might interrupt the users day. If we do logout, we could run into problems with our laptop users - as they'd go to shut down for the night, expecting to be able to leave and have to hang out for another 15 min or more while this update finishes. If we just put it in self service, well, then we know there are certain groups that won't complete the upgrade :)

So - what do you guys do? Or mores specifically, when do you guys run your OS updates?

Does my team simply need to create the understanding that these updates have to be run and it might slightly inconvenience users? Or is there a more graceful way to sneak them in?

Just curious.

ben janowski
Senior Macintosh Support Technician
Kohl's Mac Support Team
262.703.1396 | benjamin.janowski at kohls.com

When it comes to OS updates, I do the updates at logout for all of my users.
On Thu, Feb 24, 2011 at 4:37 PM, <Benjamin.Janowski at kohls.com> wrote: I generally try to break it down into groups of users so that not everyone
is getting hit at the same time. In that email I explain what is going to
happen when they logout of their machines, and that laptop users need to
plan for it and not unplug or shut their lids in the middle of it. There's
more to it, so let me lay it out:

1. I cache the update to all of the machines that need it by using a Smart
   Group. This I do during the day on a Every 15 trigger. I trigger an
   Extension Attribute to indicate that the machine has the package cached to
   it.

2. Once machines are in the "Update Cached" Smart Group, I then scope a
   policy to run at logout for that Smart Group, installing the cached package.
   The policy puts up the jamfHelper app to let the user know what is going
   on, and to re-inforce that laptop users should not unplug or shut the lids.
   This is called from a script I called lockScreen.sh, and the main contents
   of that script are:

/Library/Application
Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper -windowType hud
-lockHUD -description "$4"

I generally have "shutdown -h now" in the Run Command field of the Advanced
tab of the policy. This makes sure the machine shuts down when complete.

I've been using this method for about a year now and I've only had maybe 5
machines, all laptops, have problems, and every one of those was because the
user was in too much of a hurry. A quick re-install of the combo updater
fixed the issue every time.

Alan Benedict out of our Des Moines office whipped up some pretty cool lock
screens using the jamfHelper. He could probably share if he feels inclined
to.

I also use this method for other updates, like Flash and Silverlight, only I
do those on login.

HTH

Steve Wood
Director of IT
swood at integer.com

The Integer Group | 1999 Bryan St. | Ste. 1700 | Dallas, TX 75201
T 214.758.6813 | F 214.758.6901 | C 940.312.2475

One other thing, I cache the packages to the machines because I found that
On Thu, Feb 24, 2011 at 4:48 PM, Steve Wood <swood at integer.com> wrote:
if I didn't my JSS would get slammed all at once and the installs would take
a lot longer. This way, I can push the package during the day and not worry
about if it took 10 minutes or 2 hrs to push.

Steve Wood
Director of IT
swood at integer.com

The Integer Group | 1999 Bryan St. | Ste. 1700 | Dallas, TX 75201
T 214.758.6813 | F 214.758.6901 | C 940.312.2475

Interesting. The only problem we have is that our users rarely logout (restart,reboot etc…). Our uptimes are ridiculous.

On the upside, we do have the stick to apply updates and we'd like to do it once a month in a window that users expect. The Windows side of the house already does it. I think all it really needs is an appropriate notification mechanism and the jamfHelper to lock it out so they can't brick their machine during an update cycle. Thanks to some folks here, I've got GrowlNotify locked and loaded as our new notification mechanism. It's way more reliable, looks nicer and with "sticky" mode you know the user has to acknowledge it.

The biggest thing to us will be bringing everything up to a baseline as groups are at different patch levels. I would think the easiest way to do this would be to release an OS combo patch (e.g. 10.6.7) to everyone all at once to get them all up to it. Then go from there.

Can JamfHelper be invoked while someone is logged in? (Similar to how ARD can lock a screen.) My understanding is that it's used to prevent a log in while software installs are occurring. I'm thinking of invoking it while someone's logged in to prevent them from shutting down or restarting while software updates are happening in the background. When they're done and reboot is needed, release the screen, then give a timed reboot (5 minutes?) to give them a chance to save work.

j
--
Jared F. Nichols
Desktop Engineer, Client Services
Information Services Department
MIT Lincoln Laboratory
244 Wood Street
Lexington, Massachusetts 02420
781.981.5436

Hi All,

For those we asked,

Procedures and Rules for Patch Management at UCLan

We have strict rules over what can be updated and when, and who signs off on it, no one has admin rights to install any patches or updates, software update is disabled and only approved and tested software is available through self service, this means that our team and service can control whats on the client and take responsibility for it. Most our macs are desktops and only have a hand full of laptops.

1, Create the new image and deploy with a Post image, at reboot script, that will run a custom "ReImage" poilicy, this will then run any post image policys which are then put in a "Post image" category in Casper

After Deployment Patches

1. Download the patches (Apple, Office, Adobe CS, Flash etc etc) to my client Mac, i have full rights and uncontrolled Mac, i.e Software Update works and other restrictions are not applied but it is still managed.

2. Upload the packages to Casper Admin if possible or create a new package with Composer

3. Create a New Category called "Updates X" X = 1+

4. Update the priority if required

5. Install and test on my client Mac, test for a few weeks to a month depending on the urgency, flash are tested for a week, OS Updates for longer (10.6.6 is still on test)

6. After test if required submit to "Changemanagment" (this means everyone in the services knows whats being changed and agrees that it can be done, so should anything break responsibility is taken as a group and not an individual)

7. test deployment and that it works after deployment

Deployment Test

1. We have a growl (at login) message that runs every so often informing the customers that important updates will be installed at logout and not to restart the mac when these are in process, that way customers are informed

2. Already created a LockScreen pkg with a customer image, contains out logos and says "Important Updates are deing installed, do no restart" , there is also a LockScreen.sh script in Casper that runs the LockScreen App

3. create a logout policy in JSS (we use logout so that it does not interrupt customers and makes sure that all software is closed, also some updates can take 10mins to install) we do not bother about laptops as we only have a landful but will need to consider these soon, i think we will make a self service policy for this and customers will have to take responsibility for keeping their macs up to date, we can send an email via Casper to users who do not update their laptop within a certain time of the release, the policy is set to "at logout" , add my LockScreen as a before script, then add all the packages in the Updates X group, select update inventory (will need needed later for the smart group), then either set to reboot, if reboot required, or int he command line enter "killall LockScreen"

12 Test this policy on a test mac to see that it deploys and works, no conflicts etc

1. Create a smart group to deploy this policy, based on casper install receipts, call it Updates X

14, scope the above logout policy to the new smart group called Updates X

15, repeat for all sets of updates over the year, (Updates 1, Updates 2, Updates 3 etc and create smart groups for each, and make sure they execute 1 after the other on logout), (i name my logout policies as follow, 1.1 1.2 1.3 ...... so then run in order)

1. So that you can do the updates at reimage, you can add the updates to the post image scripts so a new mac once imaged gets all the updates in turn

Criss

On Fri, Feb 25, 2011 at 7:08 AM, Nichols, Jared - 1170 - MITLL <jared.nichols at ll.mit.edu> wrote: Interesting. The only problem we have is that our users *rarely* logout (restart,reboot etc…). Our uptimes are ridiculous.

I have the same issue with most of my laptop users. For some reason they
have it stuck in there heads that simply closing the lid on the computer is
sufficient and that their computers should be able to stay up for as long as
they need. The president and COO here are the worst. They will leave their
MB Airs up for 20 to 30 days at a time. I'm of the mindset that a machine
needs to be restarted at least twice a week, just to clear the memory and
help it run a little better.

To get around this I have a script that checks uptime on the machines. If a
machine has been up for 5 days I use GrowlNotify to lock a nice little
message that says please restart to their screen. If the machine makes it
to 10 days up, then I use the JAMF displayMessage dialog to make it more "in
your face" and kindly inform them that restarting helps to apply updates. This has worked fairly well for me, and I see that most of my users restart
their machines quite regularly. I'm attaching the script as a .txt file to
this email (change to .sh to use).

We mostly have the narcalepsy issue with our laptop users, as our desktops
are all set to shutdown each night at 10 pm. This was part of a "Green"
initiative we undertook about 2 yrs ago. I'd say that on average 15% of my
desktops get left running because someone forgot to close Firefox or close
Illustrator and they have a file open. But, by in large most of the
desktops get restarted daily.

Can JamfHelper be invoked while someone is logged in? (Similar to how ARD can lock a screen.) My understanding is that it's used to prevent a log in while software installs are occurring. I'm thinking of invoking it *while* someone's logged in to prevent them from shutting down or restarting while software updates are happening in the background. When they're done and reboot is needed, release the screen, then give a timed reboot (5 minutes?) to give them a chance to save work.

I believe the answer to this question is yes. This snippet will do just
that and allow you to put your text in as the $4 variable:

/Library/Application
Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper -windowType fs
-description "$4"

A good ole ./jamfHelper -help will list the different settings you can use.

HTH

Steve

Growl notifications that pop up every 30 seconds after two weeks of no
reboots won't force a reboot, but sure is annoying

I use that to force a reimage and it had an effect

Criss Myers

This is great info. I love seeing concrete examples of how others handle things.

We had a similar situation users rarely restarting and I was getting tired of running into performance issues that disappeared after a simple restart. So I decided to see if I could do something quickly. I ended up with an uptime extension attribute, a smart group that included those machines with an uptime extension attribute of over 10 days, and a policy that runs daily and is scoped to the uptime smart group that alerts users using a script which runs jamf -displayMessage. It works well to encourage a user to restart. Growl or jamfHelper (I've used neither) might be better/more attractive ways of notifying users and I'm sure there are more efficient ways of doing this...

Seems to work fine and I've seen my computers with over 10 days of uptime go from ~60% to ~15% of the total. The hardest part was watching the uptime display to figure out how to make sure my result was actually days. I thought I could just exclude systems that had a : in it (meaning the result was hours), but then found that if a system was polled right on the hour, it didn't have a :