macOS Big Sur 11.0 - Updated Index of Need to Know Changes & Links!

ClassicII
Contributor III

macOS Big Sur 11.0 was just announced at WWDC20!

The transition from Intel to Apple Silicon (ARM) was also announced!

The first processor name was from the keynote "Apple AZ12 Bionic".

This article will keep you updated with the latest changes, links and security information!

https://mrmacintosh.com/macos-big-sur-10-16-updated-index-of-need-to-know-changes-links/

47 REPLIES 47

davidi4
New Contributor III

anyone try to install in a VM yet?

wmehilos
Contributor

@davidi4 In a VM? Doesn't everyone just install Beta 1 on all their devices first day?

Go big or go home. 😅

amorrisuk
New Contributor II

Does anyone know what the application name is to block, as we don't want our devs to install Big Sur just yet.

TPG33k
New Contributor II

@amorrisuk the Downloaded 'Enrollment' application to install the Dev Beta profile is

macOSDeveloperBetaAcessUtility.pkg

The installer for the Beta is

Install macOS Beta.app

Not applicable

From what I read online, I guess an easy initial restriction is to block the upgrade package for macOS Catalina 10.15.6 beta named "macOSDeveloperBetaAccessUtility.pkg", one needs the beta to get the upgrade to Big Sur 10.16. At that point, you can just restrict "Install macOS Beta.app"

Cayde-6
Valued Contributor

Just tried a DEP build on my DEV instance, doesn't look like Jamf installed the binary at all. Had to use a quickadd PKG for it to enroll into Jamf

ThijsX
Valued Contributor

Jamf 10.22 also does not recognise the Disk Encryption State of a device.

sdagley
Honored Contributor II

The catch all way to block macOS installers has been to restrict the process InstallAssistant (courtesy of @mm2270), which is the GUI for the installer. Somebody should verify that with the Big Sur beta installer though.

If your users have admin rights you may also want to restrict startosinstall. The benefit of not doing that is you can call it from a policy without having to remove the software restriction, and Jamf Pro still seems to have a problem doing that in a timely/reliable manner.

jwojda
Valued Contributor II

@sdagley I just tried it on a Jamf'd VM with that InstallAssistant restricted and it still allowed the installer to go through..

sdagley
Honored Contributor II

Thanks for the update @jwojda. That is unfortunate as that process block has lasted me through the past 3 versions of macOS.

bradtchapman
Valued Contributor II

@txhaflaire : You ... did get the notice about Jamf 10.22, right?

@jwojda : I restricted in Jamf by "Install macOS Beta.app" and unchecked the "exact process name" box. Jamf was able to catch / kill the following attempts:

  • Launching Install macOS Beta.app via Finder
  • Running Resources/startosinstall via Terminal
  • Running Contents/MacOS/InstallAssistant via Terminal

jwojda
Valued Contributor II

@bradtchapman hmm, not sure why it wasn't working for me. maybe because I was on a VM? but I had full connectivity, and ran jamf manage prior to my testing to ensure I had the current restrictions.

I'll keep messing with it.

eaititig
New Contributor II

I had no luck using the JAMF QuickAdd.pkg ... it failed to install (but jamf binary was there so I guess part of it worked). Also in the logs there were references to the Jamf stuff saying:-

"(com.jamfsoftware.jamf.agent): This service is defined to be constantly running is inherently inefficient."

ThijsX
Valued Contributor

@bradtchapman Yes i did get the notification, but we are an EU cloud customer so we did get upgraded automatically and mitigations should have been take care off.

bradtchapman
Valued Contributor II

@eaititig : first of all, enrollment is hella broken in Big Sur. Jamf knows this and they're working on it.

Also, QuickAdd is deprecated and should not be used anymore. Jamf stopped using it by default after March 2018, when MacOS 10.13.2 started requiring "User Approved MDM." The package itself installs the jamf binary and then triggers jamf mdm, which uses the 'sideload' technique of installing the profile. This is 100% unsupported in Big Sur, and was also called out in the release notes as well as mentioned in the "What's New for Managing Apple Devices" presentation released today.

If your Jamf server is still issuing QuickAdd packages, you should call support and ask them for help removing the "custom JSS knobs" from your database. These tweaks are forcing Jamf to artificially offer QuickAdd packages beyond the normal supported OS version.

ncworster
New Contributor II

If anyone needs to convert the .app installer to a bootable .dmg for use in VMWare Fusion before they have official support ("early July"), here's a quick script I put together today and hosted in Self Service for our testing group:

#!/bin/bash

####################
# Notes            #                 
####################
#
# Created 20200625 by Nathan Worster
#
# This script assumes that the macOS Beta installer is already staged in the Applications folder, and will convert that .app installer into a bootable .dmg.
# To download the latest macOS beta, go to https://developer.apple.com/download/ or, if applicable, https://appleseed.apple.com/.
# The .dmg file will be placed in ~/Downloads.
# This script must be run with sudo using "sudo bash <filename>" if run outside of an MDM.
# 
####################
# Variables        #
####################

dmgName=$"macOS11BigSurBeta"

####################
# Script           #
####################

cd ~/Downloads

# Create and mount sparse volume:
hdiutil create -o install_container -size 20G -layout SPUD -fs HFS+J -type SPARSE
hdiutil attach install_container.sparseimage -noverify -mountpoint /Volumes/install_build

# Copy contents of installer .app into mounted volume:
/Applications/Install macOS Beta.app/Contents/Resources/createinstallmedia --nointeraction --volume /Volumes/install_build

# Detach the completed image:
hdiutil detach -force /Volumes/Install macOS Beta

# Convert and rename the image:
hdiutil convert install_container.sparseimage -format UDZO -o $dmgName.dmg

# Cleanup

rm install_container.sparseimage

exit 0

mpout
New Contributor II

FYI Big Sur still showing up as 10.16 when using smart groups NOT 11.0 as it's meant to! Sure JAMF know about this but that was 30 minutes of my life I won't get back figuring it out!

ClassicII
Contributor III

tzeilstra
New Contributor III

I've got Beta 2 running in a VM (thanks @ncworster !) but any attempts to go to the user-initiated enrollment page result in a configuration profile being downloaded (with the icon of a generic text file) and launching that profile automatically kicks me back to the login window and from that point forward, a few seconds after logging in, I'm kicked back out again. Had same issue with Beta 1. It sounds like some folks have gotten Big Sur machines enrolled--how did you do it? Not particularly upset about it by any means...the fact it even boots this early in the beta process is still impressive enough to me.

ClassicII
Contributor III

donmontalvo
Esteemed Contributor II

@mpout we were on an Apple call yesterday, asked them why sw_vers shows 10.16, their response was they'll be fixing that soon.

--
https://donmontalvo.com

bwoods
Contributor III

Did some testing with Beta 3 today. I'm still having issues with the Jamf binary installing via user initiated enrollment (MDM Profile). It does seem to work if I request a quick package with the UIE link.

About this mac is now show as Version 11.0 Beta.

Seeing issues with Symantec apps. (ie SEP & WSS)

Still having issues escrowing FV2 key.

mschroder
Valued Contributor

Slowly moving forward.

77Baron
New Contributor II

The Public version of Big Sur just got released today. Does anyone know if the application to restrict is Install macOS 11.0 Beta.app or is it still Install macOS 10.16 Beta.app but only says 11.0 in the System Preferences? Can anyone confirm?

DBrowning
Valued Contributor

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

antonio_derrico
New Contributor

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

mschroder
Valued Contributor

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

bwoods
Contributor III

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

terrydooher
New Contributor II

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?

mschroder
Valued Contributor

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!

barnesaw
Contributor III

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.

alvarnell
New Contributor

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

beeboo
Contributor

@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.

ICT-JPC
New Contributor III

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.

terrydooher
New Contributor II

@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.

jtrant
Contributor III

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.

bwoods
Contributor III

@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.

walt
Contributor III

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