Scheduling software updates - best practices

[#1]

We have hundreds of new machines deployed over the summer months that are
now a few revs behind in software updates. With network activity issues in
mind, I'm wondering how others set up Apple software update
pollicies/schedules to run. I'm reluctant to set them to run on start up or
log in or log out during the school day, but running them after school hours
requires others to leave machines turned on overnight with a 4PM start
trigger (I used 'any') and met with mixed success, one building ran,
another, not so much. Is anyone using a regularly scheduled or repeating
option? Once a month? What is being set as a trigger?

Please bear with the new user questions.

-- Janice K. Hill
PC Support Manager
Sheboygan Area School District
920.459.4032

[jarednichols]

Hi-

We release patches on patch tuesday that have accumulated since the prior patch tuesday. Then, we give users two weeks to run them on their own (either from Self Service which will handle the admin rights on their behalf or if they have admin rights running software update on their own.) If they don't patch by the end of those two weeks, we then force the install when they log in next.

That's the tricky part and is a bit more art than science. The problem with forcing updates in the background is that if they reboot their machine (having forgotten that they had a window telling them updates were being applied) they can break their machine. So, I came up with something that I think it's a bit more elegant (see screenshot). I created a small application that will fire off at login that quits the Finder and hides the Dock. The policy that fires off this application then does a sudo to launch Software Update. I think it's the right mix of "don't break anything but be in the user's face enough." There is the (hidden) option of bypassing the update notification if the user has a legit reason to, but I think it's enough that people will take it seriously and then run software update (especially seeing how it was just launched for them).

We can always run a report to see if there are any serial offenders who don't update even after the notification and take it up with their management.

j

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

[stevewood]

Jared it looks like you are using Growl Notify for that notification, is
that right? Looks nice.

Right now I have a policy set to run at 12 pm every Tuesday that installs
all software updates. After finishing a window pops up alerting users to
restart as soon as possible. This is all handled via Casper policies,
including the notification window.

I am experimenting with using iHook to do updates at either login or logout
and provide a dialog box. I prefer logout, just because my users then don't
have to wait for it to finish to get to their deskotp, they can simply
logout and go home. Our machines are scheduled to shutdown at 10 pm each
night, so that provides the restart that is needed for the updates.

Of course the one wrinkle in this right now is getting users to logout. So,
I may have to find another way to do this with a mixture of Growl Notify to
tell them to restart before leaving (maybe with a timed policy for 4:30 pm
each day) and iHook to alert them to what is being installed.

I am looking to use this not just for software updates that Apple pushes
out, but we are getting ready to roll CS4 out too. I want to cache CS4 to
the machines and then do a rolling update of CS4 at logout
(installAllCached).

BTW, I spoke to Jonah from JAMF last week at an Apple event and asked him to
add iHook type notification capability to the "wish list" for an upcoming
Casper release. We should have a better notification system for login and
logout installations.

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


[jarednichols]

Nope, not Growl Notify... I made it myself in XCode. I didn't want it dismissing itself after a set period of time and wanted it to stay in the user's face while software update was running.

Though, Growl Notify is something I'm looking at implementing for our notification system.
---
Jared F. Nichols
Desktop Engineer, Infrastructure & Operations
Information Services Department
MIT Lincoln Laboratory
244 Wood Street
Lexington, Massachusetts 02420
781.981.5436

[jarednichols]

If they click it, they can dismiss it.

Never leave a decision up to the user :)
---
Jared F. Nichols
Desktop Engineer, Infrastructure & Operations
Information Services Department
MIT Lincoln Laboratory
244 Wood Street
Lexington, Massachusetts 02420
781.981.5436