How to Prevent Ad-Hoc Downloads & Installs of OS X from the Mac App Store?

[dstranathan]

El Capitan is coming. How do you prevent users from obtaining the "new shiny"?

How do you prevent your end-users from downloading and installing OS X upgrades from the Mac App Store?

Obviously tis is a loaded question, with lots of options, thoughts and opinions on this subject matter.

Please chime in with your IT policies, rules and attitudes regarding allowing/preventing your users from downloading and installing OS X.

In my environment, pretty much all Mac users are local administrators (for legitimate reasons). Of course, they are all likely have Apple IDs and thus access to the Mac App Store, too. And OS X is Free! Ain't that great? Free I say!

For the last couple years my IT Director has dispatched an "official email" from IT telling users not to install the next OS X "(its not supported yet"," it needs to be tested", "You don't really need it" etc). But users sometimes ignore such warnings (or feign ignorance etc).

My team in IT can't be too heavy-handed in our approach to this challenge (i.e block all traffic to the MAS,etc)

I considered having a "seek & destroy" script running every minute looking for "/Applications/Install OS X XXX.app" and nuke it, but I don't get a warm 'n fuzzy feeling about this approach.

There are no Profiles in OS X to prevent MAS OS X downloads that I am aware of. I sure wish this was an option for us going forward in El Capitan.

Can the JAMF Casper Suite have a Policy for this?

[jarednichols]

Our IT group encourages upgrading. They publish a list of software known to function on the new OS and a list known to not work. This is for both internal and COTS software. Our environment is one of enabled self-support with the help of a help desk should you need it. Casper isn't mandated but you can load it if you want IT to handle your updates and such.

[andrew_nicholas]

We leave the App Store open for downloads but have a restricted policy for OS installs that kills the install and asks the client to contact IT if they need to upgrade their OS. If they legitimately need to update out of band, they then get added to an exclusion group for the restriction or they are pointed to the self install OS update we host in Self Service.

[dstranathan]

We have a strict set of vendor approvals have to be met before we roll any OS in production (Windows, OS X, Linux). EMC, Isilon, Microsoft, Juniper Networks, Cisco etc all need to be on the same page with us before we starting upgrading hundreds of systems. This isn't a bad best practice to subscribe to - at least in my environment.

A few years ago we discovered that OS X 10.7 Lion was causing our multi-million dollar storage cluster to kernel panic when any 10.7 based Mac would attempt to connect. It took our IT storage team and EMC weeks of hard-core analysis and observation to finally determine the issue. Understandably, hundreds of end users were grumpy and our executives quickly became aware - very aware. High-profile severity level 1 situation. My bosses demanded that EMC fly out engineers to our campus. EMC released a patch for us fairly quick, but by then the damage was done and new rules were put into place" "Never again". From then on it was mandated that all platforms must be vetted and approved by our primary 3rd-party vendors before going into production. We got burned and learned a valubale lesson. The scars are just starting to heal from that one.

We never had issues controlling OS X upgrades in the past back when...

-OS X upgrades were physically obtained from optical media
-OS X was upgraded by Apple every ~18-24 months
-OS X and cost $99 to $129
-OS X Public beta programs didn't exist

Now that OS X is available on-demand and costs literally zero dollars, there is little to no friction on the end user's side to simply click a magic button and get a brand new OS - and then complain when plug-ins break, apps crash, scripts fail, storage comes unmounted, connected devices disappear, software features are deprecated, etc.

[cdev]

We've created a software blacklist to prevent major OS X version upgrades before things are thoroughly tested in our environment. Any user attempting to upgrade receives a message informing them the software is untested and unsupported at this time. When we move to begin the upgrade process, we coordinate with groups of testers and lift the restriction at that time.

[dstranathan]

@andrew.nicholas @cdev Mind if I pick your brains on how your doing this? This might be exactly when I end up doing this fall.

[alexjdale]

When we feel the need to prevent installs, we just put in a Restricted Software entry for the OS installer that kills the process and pops up a warning to the user.

We've gone from "upgrade at your own risk if we haven't fully tested/approved it" to "total block until we can sort out third-party app issues" with El Capitan, since rootless will break multiple security applications.

We were able to allow day-1 upgrades for Mountain Lion and Mavericks since they were solid new releases and didn't break anything, but I think those days are over. Apple's yearly release cycle has impacted quality, and they are making impactful changes that are more than minor annoyances.

Honestly though, as long as we can maintain management of the system (to report on it, push new app versions, fix broken stuff, etc), a user upgrading their OS is not a critical problem from an IT perspective since the impact will generally be limited to that user, and a result of their own actions. Rootless will break Casper, so upgrading Casper to support rootless ASAP is my highest priority.

[dstranathan]

"Restricted Software" - Another reason to get JAMF.

[ernstcs]

I'll just basically state the same thing. Here we actually restrict the Mac App Store by default. Users who wish to use it are required to fill out our agreement e-form for acceptable use and then we allow their primary machine to be used with the Mac App Store.

We also restrict the OS X installers from running, at least until we've gotten our hands around it. Here again it's been more of a controlled update, you request it and we'll help you. Trying to get into Self Service mode for that again for Yosemite upgrades.

And yes...one of the many reasons to GET JAMF!

[dstranathan]

@ernstcs Is the ability to flat-out restrict the Mac App Store a canned feature of Casper Suite, or something that you scripted/engineered as a custom policy in Casper?

[ernstcs]

Just created another Restricted Software entry for that process. There aren't any built-in, but they literally take a minute to setup a new one. Just need to get the name of the process. The beauty in the OS X installers in the past is that even if someone renamed the App bundle that's downloaded the process name they can't easily change so it's still caught. At least in my experience.

Hopefully that screen shot uploaded. (yay, it did!)

[dvasquez]

We have used the restriction successfuly. We have also added the warning message as notification. I have allowed the use of the apps store as it is is required by most departments. Locking down loose cannons from downloading untested and un-vetted software has saved us big time!

[mark_mahabir]

Pretty crude, but we disable Automatic Software Update and stick the following in a postimaging script:

rm -rf /System/Library/LaunchAgents/com.apple.storeagent.plist && rm -rf /System/Library/LaunchAgents/com.apple.store_helper.plist

[andrew_nicholas]

@dstranathan Sure thing. We use the Restricted Software much as others have said, and scope it to all managed clients/servers with a few exclusion groups (IT, test machines, special snow flakes, etc.).

[dstranathan]

@andrew.nicholas "special snow flakes"? You have those too, eh? I guess I'm not alone after all. ;0)

Thanks

[bpavlov]

@ernstcs You can block the App Store through Casper or Apple Profile Manager. Create a configuration profile and look at the Restrictions payload.

[adamcodega]

To clarify how simple it is to block OS installers, here's the one we used when Yosemite first came out and we were still testing with our Wi-Fi vendor.

Also, you can use a config profile from Apple to block Beta installations.

[bentoms]

We pretty much do the same as @adamcodega has shown (profile & restricted process).

Our users are admins & we're Ok for them to use the MAS.