@77Baron the public release is call Install macOS Big Sur Beta.app

how can i prevent users from updating to the big version? i am not talking about the beta but the final big sur version?

Cheers
Toni

The safest way appears to be to install Windows on their devices.

@antonio.derrico restrict the Install macOS Big Sur.app.

Hi all,

We're already blocking the final and beta installer apps and will be hiding the system update when the time comes. One thing we never figured out with Catalina was hiding the update notification. That little red (1) was present on most machines even when no update was available (because we were hiding it). Is there a proper way to prevent this?

I don't think there is a way to prevent this. Apple is trying hard to annoy and confuse everybody with these useless notifications. I know well that Apple ID is not set set for some accounts, I don't want to see a red reminder for that!

You can't block the system update in sysprefs anymore. Time to get ready to support as soon as your mdm-enforced update delay is up.

@ncworster I believe Line 27 needs to be: hdiutil detach -force /Volumes/Install macOS Big Sur Beta

@terrydooher

i push a config profile for
com.apple.systempreferences
plist value: {AttentionPrefBundleIDs=0}

no more red dot, but its a little more nuclear than you may like.

Hi,

I've been looking for a way of preventing Big Sur hitting or being able to be installed on our Mac's. We're running Mojave 10.14.5 and it has been agreed, given the present situation, that this would need to be retained for the upcoming academic year.

@terrydooher @bwoods could I please ask how each of your suggested methods would need to potentially be implemented?

Thanks,
James.

@beeboo Good tip. Thanks. I guess this would stop all update notifications, which wouldn't fit with the way we give power users some leeway over when they install point releases; they still need to be able to see those, but definitely one for future consideration.

@ICT-JPC So far I'm following the advice of @bradtchapman and blocking the installer Install macOS Big Sur Beta.app via Restricted Software with the explicit match unchecked. (I've also added a policy for Install macOS Big Sur.app, though that's just a guess at the final installer name for now).

I've also Deferred major releases for the max. allowed 90 days, following https://mrmacintosh.com/10-15-5-2020-003-updates-changes-to-softwareupdate-ignore/ - this is because the softwareupdate --ignore function is now dead.

Between those two, I should get 90 days of deferral from the release date and from then on the installer can be downloaded but will still be blocked from running. It's ugly but it'll suffice.

Doesn't the "Defer software updates for x days" MDM payload disable major AND minor updates for the number of days specified? This looked good to me until the point I realized there was no way to differentiate between a dot update for the current OS and an upgrade to a new OS (Big Sur).

I definitely wouldn't want to defer updates for the entire fleet to buy time for Big Sur support. I'm waiting to see what Apple pull out of their hat in terms of spamming users with Notification Center popups like they did with Catalina, along with the red dot in System Preferences, but will rely on a restricted software record for now.

@jtrant & @ICT-JPC don't suggest deferring software updates for 90 days. This will prevent your software update policies for minor updates from working. I usually only defer for 7 days. But here's what you can do:

Create a Configuration Profile with the following payloads:
a. Restriction: Restrict Software Updates
b. Software Update: Uncheck all options so that users can't automatically update.

Navigate to Computers>Restricted Software>New
a. Restrict the following process name "Install macOS Big Sur.app"

Create a policy with a files and processes payload and enter the following command: sudo softwareupdate --ignore "macOS Big Sur". Scope this to all computer at recurring check-in.

Are there any resources for System Extensions like there were with UAKEL/KEXTS? I am trying to find one for Cisco AnyConnect

@bwoods Good call on the deferral. Further testing has borne out what you describe. There's no granularity of control on what specifically is deferred, so it's only good for a short-term deferral. The --ignore route however is dead to us. As of Catalina, it's not possible to ignore major OS releases. (You can ignore just about everything else, but big sur will come through regardless)

This is where we're stuck. If the only option we have is to block the installer at runtime, it gives us no facility for hiding the installer or preventing anyone downloading it. (cue lots of users trying to run it and failing and pestering IT...). It'll do the job, but Apple seem to have closed the door on other ways of hiding it.

@terrydooher I missed the part about the --ignore command being depreciated. Thanks for the heads up. I think that disabling software update will help with the Big Sur notification, but I won't know until this thing is out though. Will keep you all posted.

After software update is disabled you can run the following as the user to get rid of the red update badges: defaults write com.apple.systempreferences AttentionPrefBundleIDs 0

@bwoods @terrydooher I believe 10.15.6 brought back support for --ignore for MDM managed systems

Looks like Apple got our message.

• They are going to allow us to manage screen recording for standard users.
• The --ignore flag is gone but they're giving us more granular control on update deferrals. (ie minor, major, supplemental)

check out all of the new features here.

@beeboo How do you make a config profile with this info?

com.apple.systempreferences
plist value: {AttentionPrefBundleIDs=0}

Has anyone tried prestage with Jamf Connect and the LAPS key in the login PLIST? I tried it and it doesn't encrypt or change the prestage local account password to the encryption key. I was using Connect 2.0.1 and this was working on Catalina. I'm trying it out again with Connect 2.0.2.

Has anyone added an ARM based mac to JAMF yet? Issues?

I have not been able to find any one specifically talking about experiences managing the ARM based platform and if there are any issues or incompatibilities with JAMF management.

ARM devices only begin shipping today 17th so it's unlikely anyone has any to test with at this stage unless they had access to a test mac mini unit for dev work.