Restricted Software: macOS Mojave 10.14

[sepiemoini]

Greetings, all! We're using "Restricted Software" to prevent unwanted in-place upgrades to Mojave when it is released next week. Since this'll be in testing for a few weeks or so before our organization approves the use of the new macOS, I wanted to use this restriction workflow. I just wanted to take a moment and verify the accuracy of the process name that I am using. What're your thoughts? Is this a good educated guess based on previous naming conventions for macOS installers that Apple has used?

[ThijsX]

Hi @sepiemoini

Seems fine to me, to be sure you can also restrict the osinstallersetupd process.
See screenshot.

EDIT:
You can also add another one, InstallAssistant as well.
Because if they rename the app to Install macOS Mojave for fun.app it would still run.

[mm2270]

I block InstallAssistant, which works for all recent OS versions, and, I presume, should also work with Mojave, but we'll know for sure once it's released.
The only time this would be a problem is if you allow the regular Sierra/High Sierra installer app from the App Store to run on your Macs once you approve it. If you use something like this script, or other similar ones instead, the restriction can remain in place and you can still allow in place upgrades thru Self Service.

[sepiemoini]

Perfect, thank you both! @mm2270 we are indeed using @Rosko's workflow. All of our clients are on 10.13.6 at the moment so no need to use it until we allow in-place upgrades to Mojave. The only exception would be for using the --eraseinstall option (if needed) which @Rosko's script handles.

Do you mind providing a screen capture of your InstallAssistant restriction for clarity, @mm2270?

[sepiemoini]

This is what I've got, @mm2270:

[kstrick]

I block InstallAssistant, the App, osinstallersetupd, and createmedia.
(and then exempt as needed)

[mm2270]

@sepiemoini I'm not enabling the Delete application or Send email notification options.
The first one because, using InstallAssistant, it won't actually delete the "Install macOS Mojave.app" It will only delete the InstallAssistant binary and leave the rest of the app in place, albeit broken since it can't run with a double click anymore after that. There's nothing wrong with doing that, but if the hope was to remove the whole application, that isn't going to do it.
You could use 2 restrictions. One that blocks InstallAssistant and another that looks for the entire "Install macOS Mojave.app" bundle, with the option to delete the application enabled, to cover your bases.

The second one isn't enabled just out of preference. I don't really care to be spammed by my Jamf server about these violations. But that's personal preference only. Nothing functionally wrong with turning that on.

Lastly, I'm using a different display name, like "Block macOS installs". But that's also personal preference.

[sepiemoini · Accepted solution]

Ah, interesting point @kstrick! I very much subscribe to the "where there is a will, there is a way" mentality to an extent but just remembered that after adding both the Install macOS Mojave and InstallAssistant as restrictions, I thought about adding a few others. But because we have EFI passwords enabled for all managed Macs and no one knows the password (it's in a org-managed password keeper, duh), there's no need to worry about this. Folks booting into recovery or target disk mode to sneakily perform the upgrade will need to know the firmware password, right?

Thanks for the follow up, @mm2270!

[gpalau]

What if you wanted to accomplish this via script? Any ideas how to get it running?

[amartin253]

People definitely got creative at the HBO office today. Going to implement the additional restrictions as mentioned here tomorrow as they had some fun with renaming "Install macOS Mojave.app to get around the restriction in place currently.

[monaronyc]

@amartin253 LOL! That's great! If you guys are like us, that's exactly what happens when you give users admin rights. Great idea though with the additional restrictions! We'll do the same!

[PSU-UL]

I have the Mojave upgrade blocked via restricted software, and it works fine. We're now prepping to roll it out by department. I've added a department's static group into the scope exception, and it is still blocking those computers from upgrading. If I add the computers individually into the exception, they are allowed to upgrade.

Do groups not work in the scope exceptions?

Thanks!