Restricted Software: macOS Mojave 10.14

sepiemoini
Contributor III

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?

873b8c3d94c74d72ae92aebdc45eac87

1 ACCEPTED SOLUTION

sepiemoini
Contributor III

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!

View solution in original post

11 REPLIES 11

ThijsX
Valued Contributor

Hi @sepiemoini

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

a736a0082774428bbe8073e8bfb0931e

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
Legendary Contributor II

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
Contributor III

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
Contributor III

This is what I've got, @mm2270:

7d26166b8e3e4fb6a2e0418c4be83fda

kstrick
Contributor III

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

mm2270
Legendary Contributor II

@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
Contributor III

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!

View solution in original post

gpalau
New Contributor II

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

amartin253
New Contributor III

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.ca84352b3ea84b44a82f7d02952190a6
281a903f26bb46968dd2a3c297a54699

monaronyc
Contributor

@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
New Contributor II

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!