How to block Mavericks update

[david_yenzer]

Does anybody know specifically how to block the Mavericks update?

We are currently on JSS v8.52 using the Restricted Software function. Most of our machines are still Lion, though there have been some machines approved to move to Mtn Lion.

We currently have the following blocks in place:
Install OS X Lion.app
Install Mac OS X.app
Install OS X Mountain Lion.app
Install OS X Mavericks.app

Is there something more specific that you can provide to block the Mavericks update?

Thanks!

[spotter]

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

[mm2270]

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.

[damienbarrett]

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.

[bthomason]

It's Free!

[bentoms]

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

[solomonacquah]

I would look into OS X Server caching feature.

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

[bthomason]

is server free too?

[mm2270]

@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.

[dgreening]

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.

[damienbarrett]

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.

[david_yenzer]

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

[bentoms]

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

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

[monogrant]

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

[garyj]

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

[garyj]

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

[mm2270]

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

[TomDay]

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

[mm2270]

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. :)

[tanderson]

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

[darms21]

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

[mm2270]

@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.

[bentoms]

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.

[ernstcs]

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.

[mm2270]

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

[andyinindy]

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.

[stevehahn]

Can anyone confirm that blocking "Install OS X Mavericks" in Restricted Software also blocks it from being able to be installed through Software Update?

[haircut]

I can confirm that blocking "Install OS X Mavericks" works as it should to block installation regardless of download source.

Mavericks is installed via the "Install OS X Mavericks" app regardless of where it was downloaded from. Restricted Software will kill the process and delete the app (if you choose) with no discrimination toward how the app got on the machine or its location.

In fact, when I first downloaded the installer this afternoon, I made a copy to an external drive. Restricted Software actually deleted the installer both from my local /Applications folder and from the external volume. It is very thorough.

The only way around a block imposed by Restricted Software would be to mount the target Mac as an external disk on a second Mac and install, or to build an installer on a secondary Mac using a tool like createOSXInstaller or AutoDMG. However, if your users are going to that length to circumvent IT, that's a personnel issue :)

[ernstcs]

@mm2270 I'm now seeing a post in another thread that suggests it is indeed removing hidden admin accounts. I swore in my testing of the developer releases it wasn't. Well, that's why we test test and test some more. Sorry if I really got anyone's hopes up. =(

https://jamfnation.jamfsoftware.com/discussion.html?id=8744

I haven't looked into how the newly added upgrade your OS via the JSS native feature, but if a script already existed that simply renumbered the ID of your management account above 500 (which the binary seems to be able to figure out when it creates new accounts) then it wouldn't be bad. I know how to set it as a number, but not to dynamically find the next available above 500. I don't want to get too off topic though...

[andyinindy]

Another question (sorry if this is n00bish): does restricted software function when the computers are unable to communicate with the JSS? Such as when they are offline?

[haircut]

@andyinindy

Yes, software restrictions work offline; otherwise they wouldn't be terribly useful. The clients will need to first check in to the JSS after you add a restricted software entry; the recurring check-in will pull down updated restrictions. You can also force this by running a `sudo jamf manage` to update the management framework while you test.

[EDIT: Removed details on Restricted Software]

Just keep in mind than any changes or deletions of Restricted Software will require the client to check back in to the JSS before the change is affected.

[mm2270]

@ernstcs, no worries. I had a feeling it was too good to be true. I blame Apple for this, not anyone else. This practice of theirs of deleting accounts in the sub 500 range is asinine in my opinion. I have no issue with them adding, deleting or changing any accounts that are part of the OS as it ships, but anything else should be off limits. The problem with this, besides it breaking our Casper service accounts, is that certain specialized tools need to add some system level accounts to do background processing. So the upgrade will undoubtedly delete those as well, leaving users with some broken applications. This process makes zero sense to me. But that's Apple for you. I love them and all, but they have this terrible habit of thinking all Macs out there belong to them or something.

As for dynamically assigning a new UID to an account, that's relatively easy. Try this

#!/bin/sh

## Get the highest UID of user accounts from 501 - 999
LASTUID=$( /usr/bin/dscl . list /Users UniqueID | awk '$2 > 500 && $2 < 1000 {print $2}' | sort -n | tail -n 1 )
## Get the Casper service account's UID (adjust the account name accordingly)
SVCUID=$( /usr/bin/dscl . read /Users/casperaccount UniqueID | awk '{print $NF}' )

## Generate new UID
NEWUID=$(( $LASTUID + 1 ))
echo "New UID is $NEWUID"

## Change the service account's UID to the new UID
/usr/bin/dscl . change /Users/casperaccount UniqueID $SVCUID $NEWUID

SVCUIDNEW=$( /usr/bin/dscl . read /Users/casperaccount UniqueID | awk '{print $NF}' )
echo "Service account UID is now: $SVCUIDNEW

@bmwarren
Might want to just be careful about how much we reveal here. Believe it or not, some smart users know to lurk on these forums for juicy tidbits. Revealing too much about how Restricted Software works could give them some ideas on how to get around it. If users are local admins, like ours are, it would be trivial for them to Google how to disable a LaunchDaemon and that would be that. Just sayin'

[haircut]

@mm2270 - Good point! I've edited my post to remove the technical bits.

[tanderson]

@ernstcs I upgraded my MacBook this evening and it appears our hidden admin accounts were left in place. I'll do more testing but at least on my system they are still there.

[kenny_botelho]

You could also fire off a few bash commands that would prevent the current user from downloading Mavericks from the App Store.

#!/bin/sh

# Get current user
user=`stat -f "%Su" /dev/console`

# Assign user temp location to variable
TMP_DIR=`sudo -u "$user" getconf DARWIN_USER_TEMP_DIR`

# Remove existing Mavericks app store data
rm -R $TMP_DIR../C/com.apple.appstore/675248567

# Create com.apple.appstore if it does not exist
mkdir -p $TMP_DIR../C/com.apple.appstore/

# Send the Mavericks download to the "black hole"
ln -s /dev/null $TMP_DIR../C/com.apple.appstore/675248567

[ernstcs]

Thanks @tanderson I likely won't be getting to Mavericks stuff now until next week. So perhaps I'm not totally losing my mind...

[kirkd]

Well I hate to be "that guy" but using software restriction to prevent Mavericks from installing is not working for me.

My settings match this perfectly: http://imgur.com/nF6pLP6

I ran sudo jamf recon via terminal on my test box and tested. I can open the Install OS X Mavericks.app without issue.

Any ideas?

[TomDay]

@kirkd try removing .app from Install OS X Mavericks.app and then run sudo jamf manage?

[bthomason]

I am also able to open the App, but it kills it in a few seconds, and then gives me the warning message.

[mm2270]

@bthomason, that's how the process works. It doesn't actually stop it from being launched, but does detect its running within a few seconds.

@kirkd, follow @tommyday 's suggestion. Drop the ".app" from the Process to Look For field and then run sudo jamf manage (not jamf recon) on one of the Macs and try it again. It should work.