Moderators Josh Levitsky Posted October 19, 2022 Moderators Share Posted October 19, 2022 Just curious if folks have been looking at how to block Ventura upgrades from earlier OS versions? This is on GitHub: https://github.com/Theile/venturablocker In the FW KB: https://fwkb.atlassian.net/wiki/spaces/KB/pages/4329971/macOS+-+Block+Apple+Install+macOS+Application The FileWave KB article worked for Monterey, Big Sur and prior. I haven't been able to test it for Ventura but wanted to get a thread going so people could consider if you are going to block it, and how you are going to block it if you know you have certain apps that aren't yet compatible since it's just around the corner. 1 Link to comment Share on other sites More sharing options...
mbrownktx Posted October 25, 2022 Share Posted October 25, 2022 This post was recognized by Josh Levitsky! mbrownktx was awarded the badge 'Helpful' and 5 points. I can confirm the configuration in the second link above is working in our environment with the appropriate tweak to the "MinimumBlockedVersion" key (set to 18, the version number corresponding to Ventura) in the "com.filewave.blockmacosinstaller_user.plist" file. 1 Link to comment Share on other sites More sharing options...
Damjan Gruicic Posted October 25, 2022 Share Posted October 25, 2022 Hi Josh, thank you for good script, it works fine for me too, but it goes to start Installer second time when you leave "Blocked Installation" windows up. So if you click "OK" on "An error.." and starta again Installer, do goes to upgrade to Ventura. 1 Link to comment Share on other sites More sharing options...
Moderators Josh Levitsky Posted October 25, 2022 Author Moderators Share Posted October 25, 2022 2 hours ago, Damjan Gruicic said: thank you for good script, it works fine for me too, but it goes to start Installer second time when you leave "Blocked Installation" windows up. So if you click "OK" on "An error.." and starta again Installer, do goes to upgrade to Ventura. Thanks for mentioning that. I'll have to take a look at if there's a way to avoid the persistent person who launches it, leaves the dialog up, and launches again. We can look to improve that. 1 Link to comment Share on other sites More sharing options...
Pierre-Nicolas Posted October 26, 2022 Share Posted October 26, 2022 For our French speaking community, @Guillaume Gete shared some details on his blog : https://blog.gete.net/2022/10/24/comment-bloquer-macos-ventura/ - he's pointing to the same script as shared above, but lots of good info there (as usual ). Link to comment Share on other sites More sharing options...
Jimmy Stearns Posted October 28, 2022 Share Posted October 28, 2022 (edited) I've also tested the github package above and it's worked on all the Macs I've tested it on. I have also altered the provided uninstaller script to work with the Ventura blocker, it seems it wasn't updated from the Big Sur one. After running it allows the Ventura installer to run on the Macs I've tested it on. current_user_uid=$( echo "show State:/Users/ConsoleUser" | scutil | awk '/UID && ! /loginwindow/ { print $3 }' ) launchd_item_path="/Library/LaunchAgents/dk.envo-it.venturablocker.plist" launchctl bootout gui/${current_user_uid} "${launchd_item_path}" rm -f /Library/LaunchAgents/dk.envo-it.venturablocker.plist rm -f /usr/local/bin/venturablocker pkgutil --forget dk.envo-it.venturablocker Edited October 28, 2022 by Jimmy Stearns Deleted the emoji it auto added Link to comment Share on other sites More sharing options...
Jimmy Stearns Posted October 28, 2022 Share Posted October 28, 2022 Added a screen shot due to the forum auto changing some of the script to an emoji. Link to comment Share on other sites More sharing options...
AnEngelsen Posted January 24 Share Posted January 24 This fileset allows you to block the initial install attempt. However, if the user revisits System Preferences -> Software Update -> Update, they are able to install Ventura. They are not presented with another notification from Pashua.app. Link to comment Share on other sites More sharing options...
AnEngelsen Posted January 24 Share Posted January 24 Also, the upgrade attempt counter (consists of a FileWave Custom Field) does not appear to be working (as expected). Link to comment Share on other sites More sharing options...
Moderators Sean Posted January 25 Moderators Share Posted January 25 I already have an updated version that is due to be posted, but if the script doesn't act as expected, then it is likely it hasn't set the count and so the Custom Field is just a victim. Hopefully it will be live soon. Link to comment Share on other sites More sharing options...
Moderators Sean Posted January 25 Moderators Share Posted January 25 I've updated the KB with the new Fileset, if you'd like to test it. Link to comment Share on other sites More sharing options...
AnEngelsen Posted January 26 Share Posted January 26 @Sean, is there a reason why you choose to use both a launch agent and a launch daemon? (The previous fileset only used a launch agent.) Also, the Watch Paths key got stripped from the new/revised .plist. (Was that intentional?) Finally, I also wanted to highlight the changes to the kill_macos_major_update.sh file. (In case anyone was wondering "what changed".) Link to comment Share on other sites More sharing options...
Moderators Sean Posted January 26 Moderators Share Posted January 26 Yes two separate launch items. Users are able to disable LaunchAgents, but it has always required shell command knowledge, but it is generally easier to do user interaction with an Agent rather than a Daemon. However, with Ventura, LaunchAgents are just viewed in System Preferences and you can just tick a box to turn them off or on. Hence, Launch Daemon does the killing of the App, user can't disable that (unless they are Admin), Launch Agent informs the user; if they want to turn that off, so be it. As such, everything has been changed to adapt to this new setup. 1 Link to comment Share on other sites More sharing options...
AnEngelsen Posted September 19 Share Posted September 19 @Sean I'm getting ready to block individuals from upgrading to macOS Senoma. I noticed that the `MinimumBlockVersion` key in the .plist file is different from the minimum_block_version variable that's referenced in the .sh script. Is that correct? I'm referring to the Fileset that can be found here: https://kb.filewave.com/books/software-updates-apple/page/fileset-to-block-apple-install-macos-applications Link to comment Share on other sites More sharing options...
Moderators Sean Posted September 19 Moderators Share Posted September 19 Doesn't matter. The script 'if' block is just there in case the value is empty, but the value shouldn't actually ever be empty, the plist should always have a value. By all means alter it as you desire, but as suggested it should never be read. The example shows how you can manipulate the script with the plist to define the minimum version regardless. 1 Link to comment Share on other sites More sharing options...
Moderators Sean Posted September 25 Moderators Share Posted September 25 I've altered the Fileset and moved the trigger to a hidden file. Whilst doing this, I amended the script so that the default block version is an older version. There should never be the instance that the file is not there to supply a version, so this would be unexpected, hence blocking an older version as an error capture. The version that was in the KB would trigger the user warning if the script was to be changed; that shouldn't happen anymore. Link to comment Share on other sites More sharing options...
AnEngelsen Posted September 29 Share Posted September 29 Great! This fileset should prevent folks from upgrading via the MacOS App store. And...the MDM Restrictions profile can be used to prevent users from upgrading via the System Settings app. Word of warning, before applying any changes to an existing Restrictions profile, ensure you review and modify any unchecked settings. (New options might have been added to since the last time the profile was modified.) Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now