How to block El Capitan?

david_yenzer
Contributor II

We are currently on JSS v9.61 and use the Restricted Software function. Most of our machines are Mavs/Yosemite.

We typically restrict using both with and without the .app on the end. Do you know if there will be a space between "El Capitan"?

Install OS X El Capitan
Install OS X El Capitan.app

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

Thanks!

1 ACCEPTED SOLUTION

pitrsin
New Contributor

There should be a space, as that's how the GM installer has it. The policy I'm using is just:
Install OS X El Capitan*

That usually does the trick just fine for the betas & the full release.

View solution in original post

19 REPLIES 19

pitrsin
New Contributor

There should be a space, as that's how the GM installer has it. The policy I'm using is just:
Install OS X El Capitan*

That usually does the trick just fine for the betas & the full release.

david_yenzer
Contributor II

Great, thanks! That's what I've got right now, just wanted confirmation. In the past I also threw in additional restrictions for "Install OS X 10.11" but I don't think they do it that way.

david_yenzer
Contributor II

Might update to put the wildcard on the end like yours.

scottb
Honored Contributor

We do it for 10.10 and 10.11 using the following:

Restrict process name: "InstallAssistant"

Looks like this:

884dc9083fcf4a0a8eedad285dfce812

bentoms
Release Candidate Programs Tester

This is what we're using for 10.11

0dc81c2c774b487e972d1d3fb2131954

barnesaw
Contributor III

All you need is "Install OS X" for the process name. Been using it since 10.8 or 10.9, whenever they dropped "Mac" from the installer name.

DanJ_LRSFC
Contributor III

This might be a stupid question but surely users would need administrator rights to be able to run this? Or does it not even ask for those?

david_yenzer
Contributor II

We couldn't block just "Install OS X" if only because in our environment teachers are allowed to upgrade to Mavericks and Yosemite, but at least for now El Capitan will be restricted. So mixed bag with a lot of nuts. Might work in some environments, just not ours.

Our teachers are administrators, so they can (and do) authorize any installation that pops in front of their face. Might work in some environments, just not ours.

jonathanla
New Contributor III

nm

mm2270
Legendary Contributor III

@jonathanla Restricted Software works no matter where its being run from, so there shouldn't be a concern if its launched from another disk. The OS still needs to load a process, and that process is caught by the Restricted Software setting (if set up properly) and takes action.

FWIW, we are still using just "InstallAssistant" as the process to block and works perfectly here.

jonathanla
New Contributor III

Right, I realized it after I posted. We had a user who installed it from a DVD drive and changed the name of the installer to get around the restriction.

mm2270
Legendary Contributor III

Yep, perfect example of why I don't condone using any part of the app bundle name as the process to look for. Its been this way for as long as I can recall. Its easy peasy to get past it if someone is even marginally aware of how it might be blocking it. Block the binary name that runs and no-one will be able to get past it since they can't rename it, or more accurately, they can rename it, but they will just break the installer, doing your job for you.

Josh_Smith
Contributor III

@mm2270 Do you know if blocking "InstallAssistant" also blocks an OS upgrade package created with createOSXinstallPkg?

mm2270
Legendary Contributor III

@Josh.Smith Just seeing your post now.

I don't use createOSXInstallPkg (probably should use it more though), so I can't be certain, but my initial thought on it is, no, it should not get blocked. The "InstallAssistant" is the binary that runs which is inside the app bundle installer from Apple. Its what makes that nice big initial install screen with the Continue button come up, present in the last several OS releases from at least Mavericks and up. In other words, its the same as what you find in literally every application bundle inside the "MacOS" folder. Since createOSXInstallPkg creates an actual package installer, there's no reason I can see that blocking that binary would have an effect on those installers. Of course, its possible you might have to run createOSXInstallPkg on a Mac that doesn't have that restriction on it to create the actual package.

As I mentioned though, since I don't use this tool, don't completely take my word for it. Since Restricted Software can be scoped now, I would try scoping the "InstallAssistant" restriction to a test Mac and then run an installer made with createOSXInstallPkg to see.

tkimpton
Valued Contributor II

OS upgrade package created with createOSXinstallPkg works fine. So you can still block the App store version but serve it up in your Self Service with you required customisations ;)

mm2270
Legendary Contributor III

Thanks for the confirmation on that @tkimpton. That's basically what I figured. :)

vao
New Contributor III

Odd, none of those suggestions worked for us.

milesleacy
Valued Contributor

For the record, I'm doing a soft rollout. I've got a significant bureaucracy in my new org. There is a growing list of exclusions in this scope.1f5f73b5752e43d68011f225943eb3f5

Sirmacalot
New Contributor

I'm testing with the Sierra public Beta for stopping the Installer proces not the installer itself.
The name seems to have changed from 'InstallAssistent' too 'osinstallersetupd'.
InstallAssistant is nowhere to be found during the first part of the install.
Is this correct or does the 'osinstallersetupd' handle more then just OS installs?