How to block Mavericks update

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

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

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

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?

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

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

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

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

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

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

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?

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

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

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

It may be too late but if the culture of your company allows it, I have the app store itself blocked so no one should be getting the installer to begin with. I have the Mavericks installer blocked as well, so if I see a 10.9 machine show up in my smart group, they'll be having a huge talk with me and infosec.

At what point should I expect the Installer to quit?
I've ran the sudo jamf manage on my test box, yet I'm still able to get through the EULA and up to the Install screen.

Here's my Restricted Software setting, am I missing something?

http://imgur.com/WItmsu5

Thanks,
Chuck

@FastGM3

Since I'm not using Casper Suite 9 yet I can't really test anything, but I do know that Restricted Software under version 9 now uses the same scoping mechanism as a policy, unlike in 8.x where it just applied to everyone unless they were in the exclusion list. Is it possible your Mac just isn't in the Scope to get the Restricted Software item applied? If it is, and it still isn't working, this may be a bug.

@mm2270

I think you're right about the scoped computer, for whatever reason my first box didn't work. The second test box worked PERFECTLY!

Thank you, Thank you!
Chuck

Thanks a bunch for the help everyone. The restriction works!!

We configured email notifications for Restricted Software yesterday. At that time we were running 8.62. While at 8.62 we successfully received numerous email notifications of attempted Maverick upgrades. Later in the day, we upgraded to 8.73 and now we are no longer receiving email notifications. Anyone else come across this after upgrading to 8.73?

I don't get the restricted software email notifications in 8.72, was getting ready to call them but sounds like its a more widespread issue. Email notifications work perfectly for database backups, policy errors etc

Yeah, email notifications in Restricted Software have not worked for me for quite a while. All other email notifications work fine though.

I get multiple notifications per client. I have already got 4 users today trying to update, even though I sent an email saying don't. haha.

Under 9.2, I'm not getting any email notifications either, even though they are check on both my profile for Notifications and in the policy to send the email.

I know the policy is working, I watched the installer quit.

@pickern

I'm running 9.2 and the email notifications seem to be working just fine. Under Settings>SMTP Server, you may want to double check the account that the JSS server is sending to. Just to ensure the address you were expecting the messages to appear in, is the one setup in the JSS.

Chuck