Reboot message options

Here are a few suggestions....

1 - do not install updates at all, cache them via a casper policy instead and then flag them for install at log out or next reboot. When a user logs out or reboots, they get the update.

2 - make it a self service item, let the end user interact with it.

3 - I am sort of working on a shell script which invokes apple script for gui dialog boxes, and then outputs it to a numerical result which the shell can read. Then based on the end user's answer some commands execute. This could be used to trigger the policy. My script is a bit sketchy at the moment, but I'd share it if you really want a look at it. I am having one of the unix wizards on a forum help me with it.

4 - use smart groups or network segments to push out the updates in waves. I hope your network guy loves to set up VLANs, because mine does and it is very helpful.

Are you using a SUS or are you using Casper and manually downloading the packages, or are you using the Internet to install them?

So maybe a background on our environment:

- All Macs are portables as their desktop computer. We encourage flexibility and working remotely if needed.
- Users rarely logout or reboot. Usually when I encounter user computers, their uptime is more than a week, rebooting is never really on their mind.
- Self service is a service we already have created in house on our internal site. I like Self Service, but have no idea how to integrate into our virtual checkout system we have in place already for getting software internally.
- We're looking at getting patch compliance in place by Feb/March time frame. We want to have our Macs check weekly for Apple updates and install. If a critical update comes out, we'll create a manual one off process to push out a zero day like scenario. We've done tests like this before with VPN software and have had fast results so we know we can push out something fast if need be.
- We have smart groups in place and network segments laid out.
- For this first round of getting everyone patched, we're having them pull down from Apple. Once we get everyone patched and down to maybe two patches needed, we'll then cut over to using our JSS as the Apple Software Update Server. It's ready to roll. We see 4MB+ download speeds from Apple when updating.

I have had this same issue and have decided not to use the built in Jamf
messaging or AppleScript for messaging. I have decided to move to
GrowlNotify for notifications and am currently in the process of configuring
it for roll out.

I also have a script (written and edited by members of this group) that will
check uptime and notify a user if they haven't rebooted in over 7 days,
suggesting that they reboot so updates can be installed. I figure even if
there isn't any updates a restart is always a good thing.

Thomas, is it possible to your knowledge to cache the apple software updates
and have them install at the next logout/reboot?
--
Alan Benedict
?
Macintosh Technician
The Integer Group
O: 515-247-2738
C: 515-770-8234
http://www.integer.com

To my knowledge, you can cache anything you want, and it block copies
either the dmg or the pkg to the client. When you go to add a package
to a policy your options are, do nothing, install, or cache. Then you
can set up a new policy and under the package tab select the check box
that says install all cached packages.

So you could spend 1 week caching them all out and once they cache to
all clients, you can then create a new policy that says install all
cached policies and trigger it for start up. So when they reboot, they
install them.

I guess to add to my question, do you think its possible to cache the
updates from SUS and not dump the manually downloaded packages into Casper
Admin first? I've been try to figure that one out for a while now.

--
Alan Benedict
?
Macintosh Technician
The Integer Group
O: 515-247-2738
C: 515-770-8234
http://www.integer.com

I do not think it’s possible to cache updates directly from a SUS, only way to cache is to make it a package available in the JSS.

Craig E

If your client is pointed to an SUS, you can use the softwareupdate
binary to force a download only of the updates..

/usr/sbin/softwareupdate -d

This will only download the updates. Then later you could run the same
command with the -i switch which will install them. I would test this
out first as I am not sure exactly how it will pan out.

Just spit balling here, but perhaps using the -d switch for the
On Fri, Jan 22, 2010 at 10:25 AM, Alan Benedict <abenedict at integer.com>wrote:
softwareupdate application would do this. I haven't played with using the
-d switch, and don't know if it performs in the same manor as the cache
functionality in Casper, but it would be worth a try. I could see this play
out like this:

- Machine on internal network, wired or wireless
- Policy triggers to cache SUS updates via a shell script that simply says: softwareupdate -d
- Second policy scoped for logout then installs the updates via: softwareupdate -ia

It'd be an interesting lab experiment. I don't have time today for it, but
I might look at it next week if I remember.

Thoughts?

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
Sent from Dallas, TX, United States

But once you perform the –i doesn’t it grab anything from the SUS as well, and not just what you downloaded?

I honestly don’t know, but that’s why I answered the way I did. If you want to control EXACTLY how and what is installed do it in the JSS. However, if you want some control, but want it more automated use a SUS.

Craig E

- Machine on internal network, wired or wireless
- Policy triggers to cache SUS updates via a shell script that simply says: softwareupdate -d
- Second policy scoped for logout then installs the updates via: softwareupdate -ia

It'd be an interesting lab experiment. I don't have time today for it, but I might look at it next week if I remember.

Thoughts?

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
Sent from Dallas, TX, United States

It might grab everything (especially with the -a switch too), but as long as
you are doing the install on the same day as the download you should be
good.

Besides, if you are pointing to an internal SUS server you control what
updates are available. So you wouldn't necessarily have to worry about
Apple releasing a new update between the download and the install.

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
Sent from Dallas, TX, United States

Last spring when Apple was on campus with us doing our proof of concept Mac pilot, we ran into this issue as well. We pushed a patch that required reboot and a several users were upset. They are used to the ability in Windows to delay their reboots up to 4 hours and do the reboot on their own time.

To alleviate this issue, I wrote the following script. I'll paste it below and try to attach it. I'm not sure if the mailing list to strip it off or not. It's not perfect but it works pretty well to put at the end of a policy rather than using the built-in casper reboot options. It's customized for my organization so you may want to change some of the wording of the dialog boxes and do thorough testing but it might get you started.

----------------------------------------------------------------------

Nice script, I was doing the same thing but with a combo script of both shell and apple script. I had someone help me write this as I am not huge on apple script vocabulary at the moment.

#!/bin/bash - IFS=$' ' declare -x PATH=/bin:/usr/bin:/sbin:/usr/sbin

message='Hello World!' ASerror=1 # assumes worst case to err on the side of caution

# function to parse the string (1st arg is the full text, 2nd arg is the desired field): parse () { echo "$1" |sed '1!d;s/^.'"$2"':([^,]).*$/1/'; }

: # (*your* other script lines) :

# here's where we present a dialog... # redirecting fd2 to dump AppleScript's error text when Cancel is clicked: reply=$(2>/dev/null /usr/bin/osascript <<-AppleSkript tell application "System Events" set frontApp to (name of (some process whose frontmost is true)) as text end tell tell application frontApp display dialog "$message" with icon note end tell AppleSkript ) ASerror=$? # capture exit status!

# dialog is dismissed, so what happened? clicked=$(parse "$reply" 'returned')

# seems best to test for cancel click via exit code FIRST: if [ $ASerror -ne 0 ] then echo 'use hit cancel' # do whatever

else echo "user clicked on: $clicked" # do whatever fi # I used the dialog's status next just for test purposes... exit $ASerror # <-- put whatever exit code you like instead

It basically tells apple script to output a numerical result based on what it finds and then reads either 1 or 0 and then executes a command. I find shell scripts to run faster and have less over head, and I know shell a lot better than I know apple script at the moment.

I like your script though.