How to block El Capitan?

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.

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

We do it for 10.10 and 10.11 using the following:

Restrict process name: "InstallAssistant"

Looks like this:

This is what we're using for 10.11

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.

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?

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.

nm

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

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.

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.

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

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

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

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

Odd, none of those suggestions worked for us.

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.

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?