Software Update - laptop labs, progress indicator

I suggest you look into an ongoing policy that caches the updates and then once every laptop is cached the proper updates you can trigger them to install from cache. That way you can kind of control when they update and reboot. That way you can push them out to cache and let them sit there then say, OK, on Monday I am going to tell all clients to run these updates from cache and wham, you are done. You also have it narrowed down to run on one day.

Just a thought.

Or you can look into self service and have the end user trigger it.

That's how we'll be doing it as you mentioned in the end. User will be able to run them when they wish through self service. Might have a policy that does a real basic display message to the user that new updates are available to them to install using self service. That's for office users.

In our lab laptop carts it's more up to us or the faculty responsible (us) for it to run updates when we tell them new ones are available or when a security issue exists. They don't want to be doing that anytime around a class period if there is potential to lose class time. Those systems aren't assigned to students, they just sit in a cart unable to update while a sleep unless someone goes to them.

As far as the indicator goes, not sure what value that really has. If you know they need to update just run them until their done. Sure it looks pretty.

Craig E

What we have been doing is just pulling them off the cart, running Casper Remote on them and telling them to "Install all available updates". Its a pain, but it seems to be the best way to do it.

For the progress bar, we have a Unix command to run Software Update as sudo which allows non-admins to install them. This is set as a Self Service policy (the last tab allows running commands). The command is:

sudo /System/Library/CoreServices/Software Update.app/Contents/MacOS/ Software Update

It gives them a nice UI to run them. We've had good feedback about it, and it saves us from forcing them.

-Matt

There is also a softwareupdate binary from the command line. You could create a policy to run or do it via ARD admin

$ softwareupdate usage: softwareupdate <mode> [<args> ...]

-l | --listList all appropriate updates -d | --downloadDownload Only -i | --installInstall <label> ...specific updates -a | --allall appropriate updates -r | --recommendedonly recommended updates

Per-user preferences: --ignore <label> ...Ignore specific updates --reset-ignoredClear all ignored updates --schedule (on | off)Set automatic checking

-h | --helpPrint this help

If you have a SUS set up you can say run all approved updates from the SUS and such.

Sitting in a cart powered off or asleep seems to be the main problem here. You can use MCX (via scripting or WGM) to schedule a boot/reboot/wake time. If you schedule this during off-hours, and then have a software update
policy following closely behind, this should solve the issue, assuming the
machines are connected to your network while in the cart.
At one school I worked with, we had a closet built with a secure lock,
ventilation, power and ethernet. The laptops went into this closet over the
weekend where they could sit on the network and receive any maintenance or
updates.

----------
Miles A. Leacy IV

? Certified System Administrator
? Certified Trainer
Certified Casper Administrator
----------
voice: 1-347-277-7321
miles.leacy at themacadmin.com
www.themacadmin.com

Wait a second--Is it possible for a laptop, closed and in a cart, to run scripts and such? If so, will it go back to sleep when it is done, and is heat an issue? (The carts are ventilated, mind you.)

Also, is it possible to throttle software update? If I wanted my clients to download the updates while the computers are in use (and not hammer the network too hard), is there any way to do that (preferably on the client side)?

Cheers,
Clinton

No it is not possible from what I understand. If it is powered on but
the lid shut it kills all network connections. I know it kills my ssh
sessions when a user closes their lid. I have had it done to me quite
often. I will get them on chat, tell them that I am ssh in and will fix
their issue with out them knowing it. I say ok the command is running
but needs time to complete, they close their lid and move along, and my
session was murdered.

On Thu, Apr 2, 2009 at 12:19 PM, Clinton Blackmore <clinton.blackmore at westwind.ab.ca> wrote: Wait a second--Is it possible for a laptop, closed and in a cart, to run scripts and such? If so, will it go back to sleep when it is done, and is heat an issue? (The carts are ventilated, mind you.)

I haven't done this in a while, so I don't recall. It's definitely
something worth testing.

Also, is it possible to throttle software update? If I wanted my clients to download the updates while the computers are in use (and not hammer the network too hard), is there any way to do that (preferably on the client side)?

I don't know and, in fact, I think you can't throttle from the client side. You can throttle from the server side if you're running your own internal
SUS. I recommend an internal SUS to anyone who manages Macs. It's
relatively simple to set up, and it lets you control if and when updates get
applied, which is important because Apple updates can sometimes break
customizations and/or software that doesn't follow Apple's development rules
(such as Microsoft and Adobe titles).

In that case, how do you throttle it on the server side? We are using internet SUSes (although we really want to get a cascading SUS setup, so we can set on one server which updates need to go out, and which ones should be avoided.)

I don't suppose anyone has a way to multicast software updates?

Why the sudden interest in software updates? Well, we normally go with the policy that computers that are on our network will be updated when they are imaged each year, and beyond that, few things are critical enough to warrant it. Unfortunately, we believe that upgrading all of our clients will resolve some issues we've been having, and, so, we are updating. [BTW, has anyone seen a good writeup on the AFP bug that 10.5.6 is supposed to address?]

Clinton

1. Will bandwidth throttling via your own SUS carry through if Casper policies are applying updates?
   1. I'm dealing with the same issue as Clinton; I have more than 500 laptops strewn throughout campus in carts, and they're all using 54Mbps wireless, so updating (and general connectivity) can sometimes be a pain. I was thinking of deploying Self Service to all the machines and adding it as an allowed application via WGM only to computer groups that I want to have updated, so at least updates can be scattered and somewhat managed on a computer group to computer group basis. I'd add a loginwindow message letting students know there are updates available and to run Self Service when they log in. I don't know if that's the best solution; I'm still wrestling with it in my brain.

Otherwise, you could set updates to run at startup or via the "any" trigger, but my experience with that has been mixed. I've tried to run updates at startup and users will get upset that it takes forever to log on, and I've tried it at "any," which seemed to work better, but can still impact performance and the user will get weary if they don't know they're receiving an update. I think my experience also has to do with the fact that all the machines are wireless, and connectivity becomes heavily impacted when there are more than a few dozen machines pulling down large files from the server simultaneously.

- Jeff

By "internet SUSes" do you mean Apple's SUS(es)? How large and in how many
On Thu, Apr 2, 2009 at 12:33 PM, Clinton Blackmore <clinton.blackmore at westwind.ab.ca> wrote:
disparate locations is your deployment? I ask, because a single SUS should
suffice for most deployments up to a few hundred machines, provided you run
your updates in off-hours and have a relatively fast network. Cascading
SUSes are typically used when you have a large number of clients and/or have
clients that are in multiple locations and you don't want your SUS traffic
going over WAN links.

Closing the lid invokes sleep. What I'd be interested in testing is if you
can wake/boot/reboot the target machine while the lid is already closed, and
gain network access.

----------
Miles A. Leacy IV

? Certified System Administrator
? Certified Trainer
Certified Casper Administrator
----------
voice: 1-347-277-7321
miles.leacy at themacadmin.com
www.themacadmin.com

Ack. I meant "internal" SUSes, not "internet".

Clinton

On Thu, Apr 2, 2009 at 12:40 PM, Jeff Strauss <jstrauss at loyolahs.edu> wrote: Will bandwidth throttling via your own SUS carry through if Casper policies are applying updates?

Yes. Casper says "go to SUS 'X' and get all available updates". The update
process is still governed by your SUS settings.

I’m dealing with the same issue as Clinton; I have more than 500 laptops strewn throughout campus in carts, and they’re all using 54Mbps wireless, so updating (and general connectivity) can sometimes be a pain. I was thinking of deploying Self Service to all the machines and adding it as an allowed application via WGM only to computer groups that I want to have updated, so at least updates can be scattered and somewhat managed on a computer group to computer group basis. I’d add a loginwindow message letting students know there are updates available and to run Self Service when they log in. I don’t know if that’s the best solution; I’m still wrestling with it in my brain.

In general, and because one must cater to the least adept user, I leave end
users out of management tasks. Self service is great for things that the
user wants, such as an application, a peripheral driver or a printer, but
for items that the end user cannot see any tangible benefit to, they're a
lot less likely to actually run the self-service policy.

I'd suggest that if waking a machine with the lid closed turns out to be a
dead end, to find a room that you can be sure will be and remain locked on
weekends (preferably a room with lots of table/desk space and power). As an
end of week procedure, plug in and open up your laptops in this room. Get a
student volunteer(s) to help you if you can.

Otherwise, you could set updates to run at startup or via the “any” trigger, but my experience with that has been mixed. I’ve tried to run updates at startup and users will get upset that it takes forever to log on, and I’ve tried it at “any,” which seemed to work better, but can still impact performance and the user will get weary if they don’t know they’re receiving an update. I think my experience also has to do with the fact that all the machines are wireless, and connectivity becomes heavily impacted when there are more than a few dozen machines pulling down large files from the server simultaneously.

Laptops can be a bit of a pain for routine maintenance since you can usually
never be sure when and for how long they'll be on the network. What I have
done and suggest is that you convince management (or school administration
or whatever serves as the "authority you don't question" in your
organization) that in order to provide security/stability/meet SLAs/etc.,
you need to have it mandated that laptop users bring their laptops in to
stay on the premises overnight once every 'X' days. That X will be
determined by your specific environment's needs. When the user brings their
laptop in, you plug it into the network, and let the updates run overnight.

One thing you can do is:

(optional) create a policy to download the updates (run the command "softwareupdate --download --all")
create a policy with a custom trigger to install the updates.
Trigger the custom policy from ssh or remote desktop.

I actually just started on a screencast on how to do just that, and am toying with putting it on the net. But it is pretty simple:

When you create your policy, where it says "triggered by" choose "other (Manually specify the run at action in this field) -->" and in the specified field, put in your trigger, ex. "software_update" You may want to set your policy to ongoing (so it'll run whenever you trigger it) and the scope to all computers (there is no harm if you never trigger it on a machine you don't want it to run on).

Then, with ssh, you would do:

sudo /usr/sbin/jamf policy -trigger software_update

or use the appropriate trigger for the last parameter.

From Apple Remote Desktop, you would select your target computer, tell it you have a unix command to run, tell it to run as root, and use the same command (but without the sudo). It is handy to add it to the Templates (the drop-down in the upper-right-hand corner in ARD when specifying a unix command).

Hmm... One of the machines I've updated today (from a policy) has kernel panicked. Maybe I can't attribute the earlier panics to user error. When I talked to JAMF about it, they'd not heard of the issue, and they also mentioned that you should avoid the "any" trigger unless you really need to use it.

Cheers,
Clinton

Far as I know not possible, but I've wanted that capability for this exact scenario. Sometimes you can make the systems fit in the cart (some carts anyway) with the lid open just enough to keep them active in the cart, but you're still going to be the one over there making that happen.

If the lid is closed...the system is just not accessible...period. This is probably for good reason in most other circumstances like someone that has their laptop in a laptop bag and then it kicks off, heats up to no end, then melts the system down because it's suffocating.

Should it be allowed...hell yes, but don't go crying to Apple if it's misused and ruins hardware would be my guess. =)

Craig E