How to block Mavericks update

Once Mavericks was announced I created the following under Restricted Software...

Display Name: OSX 10.9
Process To Look For: Install OS X 10.9
Kill Process: Checked

We're currently blocking it, successfully, and we just have the following entered for the Process to look for:
Install OS X Mavericks

Works for us. You could add one like above and another with the .app at the end, but I don't think the latter is necessary. Restricted Software is using the process list as it shows up on the command line, not the GUI.

This is how I'm blocking the OS X 10.9 upgrade for my users. A smart user can simply rename the app and it will still run, but this is a great first level of defense.

http://imgur.com/nF6pLP6

I also have a smart group set up to look for any machines running 10.9.x with it set to email if if detected. Then i can follow up with the user to discuss AUP violations and infractions.

It's Free!

Wasn't going to block when paid for, but now... Err...

I would look into OS X Server caching feature.

http://www.amsys.co.uk/2012/blog/os-x-server-caching-service/#.Uma4uJGIqU6

is server free too?

@damienbarrett wrote:

A smart user can simply rename the app and it will still run,

Which is why you don't want to use the "app" but rather the executable inside it. Just drop the .app label and it will still block it because that can't be renamed. Well, it can, but it still shows up the same way on the process list.

In testing we found that if the process you add is simply "Install OS X Mavericks" what happens is, if the user doesn't rename or modify it. it will block and (if you set it up to) delete the entire "Install OS X Mavericks.app" bundle.
If they rename it, it still blocks it but only deletes the executable inside /Install OS X Mavericks.app/Contents/MacOS/, but leave the rest of the app bundle. But effectively its toast since you can't launch it without that executable. So the user will have no choice but to re-download the whole thing and try, and fail, again.

You all might want to implement this ASAP since Mavericks is available today.

Sure, its free, but we are still going to block it, as OS installs stomp all over our hidden admin accounts (sub 500 users). I have a workflow in Casper that updates Macs (previously to 10.8) without the issues with the admin accounts.

Mike, that's an awesome tip. (restricting the executable process instead of the .app). Thanks.

We will eventually being upgrading our users to 10.9, but on our schedule, not Apple's. There's all kinds of vetting and software compatibility checks we have to run before we can sign off on 10.9 upgrades. We'll cache 10.9 to the JAMF waiting room and put an installer in Self Service when we're ready for our end-users to upgrade, but not until then.

Just saw that it's free. We're still blocking it at least until we can test it. Thanks for the tips everyone.

Hmm.. A lot of our stuff is scoped via OS.

We may alert & not block.. Create a smart group & chastise appropriately.

@bthomason No, Server is still $19.99 http://www.apple.com/osx/server/

I have never blocked anything before but followed the example above. I can still launch the installer. What am I missing?

Okay, it's working now. It had to refresh to my client

@garyj, yep, the setting gets pulled down next time the Mac checks in.

Awesome tip, working on it and testing now! Thx very much

For all of you testing this out, if you choose to have the Restricted Software item delete the installer, make sure you make a backup of it to another location before trying it out. Don't do what I did the first time and just run it, and watch as the jamf binary dutifully deletes the whole thing from your Mac. Whoops! :S

Sucks to have to re-download a 5+ GB installer. :)

Thanks for the tips. Have it set up and ready to go.

From the JSS - how can you determine that the restricted policy setting actually had to kill the process on a client?

@darms21 - You can't from the Restricted Software item itself, but if your JSS account is set up to receive emails on Restricted Software violations, it will show you the info of what it did, what machine it did it on, etc, in the email you get.

Thanks @mm2270.

I've added the kill command & a nice window to prompt notify the users & advised them to email the service desk to be added to the beta.

I think someone posted that they were concerned about hidden accounts (under 500) being "whacked", I don't believe that's the case with the Mavericks installer now.

@ernstcs, Really? If so, that will be a welcome change. I never understand why the installer removed any accounts anyway.

FYI, it looks like the Mavericks update is appearing in software update, even though we have not enabled it on our SUS. We are thinking of blocking access to the Apple software update servers to prevent this.