We are not ready... Big Sur

[mojo21221]

I was looking to see how other admins are handling the impending Big Sur update. Though most of my testing has been positive I still have a few apps that need some polishing. With that said what are the recommended methods for preventing Big Sur from coming down to the fleet? Are people using the Configuration Profile > Restrictions > Functionality> Defer Updates? Any thoughts on https://github.com/hjuutilainen/bigsurblocker. I have never had much luck with the Restricted Software Payload. It always seems to let a few through here and there.

[rmckellar]

@mojo21221 I've been testing the bigsurblocker, and it seems to work quite well. It's also easily removed for when you do want to deploy Big Sur to your fleet.

[mojo21221]

@rmckellar I think that will be our solution. I was a little unsure if it will work with all releases of Big Sur or just the current betas. Thoughts?

[rmckellar]

@mojo21221 It looks like it restricts all Big Sur releases.

[davidi4]

"bigsurblocker"?

[alexjdale]

Why use bigsurblocker over Jamf's restricted software feature? It looks like it does the same thing, but with more steps.

[rmckellar]

@alexjdale That's a great question. The reason I'm utilizing it is because I've had hit-or-miss success with the macOS updates in Restricted Software. This also looks at the CFBundleIdentifier and kills the app. It's a little more intrusive, but more accurate than looking for an app process. I've also had Restricted Software for an app process work in one OS version and not in another, where I had to change the name of the process. So, really, for me, utilizing CFBundleIdentifier makes me more comfortable.

[MLBZ521]

Using the Jamf Pro Restricted Software feature is not reliable.

You either:
1. block the app by the app's name, which all the user has to do is rename the .app application bundle and you've bypassed the restriction -- aka not very hard at all
2. block all upgrades by using the process name; so if you had only wanted to block one upgrade version, you prevent your users from upgrading at all

I have a customized fork of AppBlocker (same thing that hjuutilainen's bigsurblocker is based on) as well that allows you to specify what you want to block (instead of solely a single app). I designed it to allow a more immediate update to the block list using Config Profiles to manage the list.

While all these options do block the Bundle ID which can be changed as well, it's at least a little more difficult for the average user to accomplish.

[LRZ_Jamf]

Would you like to share your tool @MLBZ521 ? It sounds very interesting!

[MLBZ521]

I guess I forgot to share a link.

https://github.com/MLBZ521/AppBlocker

There's more customization that mine allows that I didn't describe above, but should be described in the README.

[jameson]

If users rename install app or other smart things, then it is more a HR issue than a system. My users are informed that it is blocked and they should not install. So if any do smart workarrounds to get it working, I will just say here you go, and the user can support it on his own

[ckulesza]

Dumb question from a N00b on this. How do I implement either app blocker or bigsureblocker?
Edit
Never mind my brain is not working this morning

[hdsreid]

@jameson i'm glad i can get away with the same thing

[horganj76]

Couldn't you also use the Defer Software Update payload in a config profile?

[mhasman]

Would that work, running daily?
softwareupdate --ignore "macOS Big Sur"

[jtrant]

@horganj76 yes but this defers ALL updates, not just OS updates.
@mhasman this works, but it's easy for the user to get around this by renaming the installer.

[ckulesza]

I ran the package for the bigsirblocker and the update is available. So I am just going to use the payload.

[MLBZ521]

@mhasman The --ignore switch on softwareupdate --ignore is no longer supported. Support was removed in Catalina for a few version as well. Thanks Apple.

So you could use it, but not for specific Catalina versions and isn't supported at all on Big Sur and forward. Apple does not want you blocking OS upgrades.

Supposedly the Defer Software Updates Config Payload will eventually support passing versions with it, so you can specify what you want blocked. I keep seeing this described by Jamf in their Webinars for a while now, but no idea when that functionality is coming. Nor how you're supposed to manage it. Push a new Config Profile for every new version? As per normal, Apple's device management concept is poorly conceptualized.

[mhasman]

Thank you @MLBZ521

> Apple does not want you blocking OS upgrades

Apple, guess what, macOS is not only software running on enterprise Macs this days. There are so many software, tools, clients, services, and all of those should be updated, tested and approved until there is any chance business users loosing productivity because new shiny macOS is not compatible with, yet

[mhasman]

Please share config profile you use for booking the BS, and steps to set it up on JSS

[MLBZ521]

@mhasman I completely agree. I would highly recommend sharing that with your Apple reps.

Also, the --ignore switch change is documented here: https://support.apple.com/en-us/HT210642

Apparently, on the latest versions of 10.13, 10.14, 10.15, to use it, the device has to meet specific conditions. I hadn't read that. Enjoy

[MLBZ521]

The Configuration Profile is under the Restrictions Payload. Defer Software updates for X-days (maximum of 90 days is allowed).

[rvarnas]

Network logins on Big Sur using LDAP led to endless MDM profile approving popups. Anybody using Big Sur with JAMF + LDAP?

[MLBZ521]

@rvarnas In our labs we use LDAP for logins, but those are Catalina. Not sure when we'll test Big Sur at this point.

[dgreening]

For Catalina, as long as you are UAMDM / ABM managed, the ignore still works:

https://derflounder.wordpress.com/2020/11/12/preventing-the-macos-big-sur-upgrade-advertisement-from...

[MLBZ521]

@dgreening Only if you're on the latest security patches.