How are we supposed to manage Big Sur updates on the M1 Macs now?

[abnaau]

Before the M1 Mac's we used the softwareupdate command line tool to download and install updates - and force a restart after a 48 hour deadline has passed.

On M1 Mac's with Big Sur this fails because softwareupdate now needs a user password in the middle of the upgrade. No amount of sudoing will help.

Then we have the "Download and install software updates" management command, which:
- Cannot be issued as a policy
- Cannot be deferred
- Cannot be scheduled
and worst:
- Still needs the user to enter the password! Simply clicking cancel fails the updates :(

What are we supposed to do now? Our security team is not happy that our brand new mac's are potentially running insecure versions of macOS indefinitely - especially after we just taught everyone that security updates will be automatically installed within 48 hours.

[mwu1876]

I just posted about this yesterday. Haven't heard anything and can't find much online.

[abnaau]

Some of our users are so paranoid they refuse to enter their password into anything that looks the least bit suspicious.. And sadly the new password dialog looks "a lot suspicious".

[poormatt]

Sent feedback to our rep on this. Been working this issue a while, both with the softwareupdate and the startosinstall commands. Not sure that it'll gather much attention but it's frustrating being forced into bad practices, especially when the man page is inaccurate:

"softwareupdate requires admin authentication for all commands except --list. If you run softwareupdate as a normal admin user, you will be prompted for a password where required. Alternatively, you can run softwareupdate as root and avoid all further authentication prompts."

Hopefully it's a blip that was an oversight or gets fixed soon, but it's a pretty big one.

[UbiquitousChris]

There are several open feature requests on improving this. Make sure you all upvote:
https://www.jamf.com/jamf-nation/feature-requests/10116/implement-software-update-with-bootstrap-tok...

https://www.jamf.com/jamf-nation/feature-requests/9281/improve-ux-ui-to-execute-mdm-commands
https://www.jamf.com/jamf-nation/feature-requests/9926/ability-to-run-mdm-commands-from-jamf-binary
https://www.jamf.com/jamf-nation/feature-requests/9927/ability-to-create-new-mdm-policies

[JamfMyMac]

Any one have update on this?

[jefff]

I think some of you are barking up the wrong tree. This is not Jamf's issue to fix, when the Terminal command softwareupdate works this way on an unmanaged Mac running Big Sur. Three versions into Big Sur, it's becoming clear that updates are working as Apple intends for them to work.

IMO, it's time to move on to a combination of user education and stronger measures to prompt users to update, like Nudge.

[jtrant]

@jefff sure but what about headless Macs (e.g. servers, Zoom Rooms)? Manually pushing MDM commands instead of a scheduled policy is not feasible. Apple know this and definitely need to address.

[jrippy]

@jtrant Unfortunately, they (Apple) just don't care. Like @jefff said, they see it working as they intend for it to work. It sucks for business but they want everyone Mac to be used as if the user was the owner. They still allow some supervision ala MDM (Go Jamf!), but their ideal environment would be probably very similar to IBM's model. The computers themselves are free to use as the user sees fit and are essentially disposable. Any "business use" is via applications and other secure, no trust mechanisms. Nothing important on the computer itself. The computer is just the vessel to get to the data and the rest of the computer is for the end user to play with.

[AJPinto]

All of this update business is putting us in a bad place. We are discussing zero trust options. Basically if a Mac is out of date for a period of time it is totally locked down. In enterprise the general concept is users cannot be trusted and generally this is very true in most cases. It is very unfortunate that this is literally what Apple is intending. However, we are all paying JAMF to provide solutions for "organizations to succeed with apple". Software Updates have been a long standing weakness where JAMF has done nothing to enhance the experience.

With 11.3.0 released last week a security patch quickly followed it up with 11.3.1 and you really have no reliable way to force that update to install on Apple Silicon devices. JAMF still does not fully support "schedule an update" never mind they recommend using it to managed updates and we all know the complications of Auto Updates. The best I can recommend for everyone who sees this is to start blowing apple up with feature requests, and prod your JAMF Reps on the pending feature requests JAMF has.

[snowfox]

M1 Apple Silicon devices are 'required' to go through Automated Device Enrollment if you want to send remote update MDM commands to them via a mass action task. Otherwise you have to go into each devices starup security utility in the recovery console to enable the tick box. It's mentioned in this document Deploying macOS Upgrades and Updates with Jamf Pro

Note: On computers with Apple silicon (i.e., M1 chip), users may be prompted to authenticate before an update can be installed. There are additional requirements for computers with Apple silicon if you want the update to be installed automatically without user authentication: Bootstrap token for target computers escrowed with Jamf Pro The Allow remote management of kernel extensions and automatic software updates option enabled in the Startup Security Utility (in macOS Recovery) For more information about how to enable this setting, see Change startup disk security settings on a Mac with Apple silicon from Apple's support website. Alternatively, enrolling computers with Jamf Pro via a PreStage enrollment can automatically enable this setting.

[snowfox]

Ok starting to tear my hair out with this. My M1 test machine has:
Been though Automated Device Enrollment. The serial is in Apple School Manager.
It has a Bootstrap token escrowed with Jamf Pro.

The default setting in startup security utility is 'full security'. Which makes macOS behave like an iOS device. Putting the device through ADE didn't change anything. We're on Jamf 10.28. Will try upgrading to 10.29. Secure token for the user could be an issue. Not sure Jamf Connect creates one :/ Haven't seen any prestage enrolment settings to set 'reduced security' for M1 devices and auto tick the allow remote management of software upates button.

I notice startosinstall on Big Sur now has an extra option --reducedsecurity could be related to the above for M1 devices.

Fun and games...

[snowfox]

Kernel extensions in macOS

[gavin_pardoe]

You can varify if Jamf Pro has escrowed a bootstrap token with the below:
sudo profiles status -type bootstraptoken

If the token has has been escrowed you will see the below:
profiles: Bootstrap Token is supported on server: YES
profiles: Bootstrap Token escrowed on server: YES

For me with the token escrowed and reduced security enabled with “Allow remote management of kernel extensions and automatic software updates” selected im still prompted with a password for updates.

[snowfox]

@gavin.pardoe Thanks for the info. The statements from Jamf documentation surrounding this feature are so far, vague. I will continue to read up on it...

[snowfox]

Silent Knight states the following:

even with the setting ticked and reducd security enabled, DEP approved MDM operations are still nope.

I've now also discovered if you do a startosinstall --agreetolicense --eraseinstall --passprompt command on a device that has reduced security enabled in its startup security utility, it will reset the setting to full security by default and disable your tick boxes. I tried adding --reducedsecurity and the upgrade failed at the recovery console, had to roll it back. This may have been because reduced security was already manually enabled. It could also be a 'feature'.

[snowfox]

Upgraded today to 10.29. Don't see any difference compared to 10.28
Put my test M1 device through ADE. Full Security is still the default boot state and DEP approved privileged MDM operations = No
I have confirmed that a bootstrap token is escrowed with the server.

[Jason33]

I've resorted to having the users manually check for updates. Nothing I've tried from Jamf has worked, and even mass action is broken at the moment for updates.

[kacey3]

We recently updated to JAMF 10.30.1 and still are unable to force OS updates. This is getting extremely frustrating as I have 200+ lab and classroom computers that remain unattended at all times and will be needing OS updates regularly.

[AJPinto]

@kacey3 JAMF really has no functional way to manage macOS updates, and Apple Silicon just made matters worse. It is long past JAMF to get their mess together on this. We have decided to skip Apple Silicon in our environment until MacOS 12 comes out which adds some controls for macOS updates.

Apple should have done this Bootstrap/Secure token thing at the same time with adding the preference domains to manage it. Its absurd how in Big Sur there are no user notification or deferral options for updates, the machine just goes down when the updates download and that is it. Assuming the updates work at all, and best yet no logging or reporting by default; you have to build all of that. How they want you to deal with macOS updates now Big Sur (on Apple Silicon) is absolute trash in this regard and this should have been addressed by 11.1 or 11.2 at latest, certainly not waiting until macOS 12.

< /rant >

[dgreening]

It is extremely annoying at the very least that OS update compliance has essentially been broken for a full OS release, and only looks to be fixed in the next OS, which is MONTHS away.

[sdagley]

@AJPinto @dgreening If you have access to the macOS 11.5 beta release notes you might see some promising news in there regarding changes that will land before macOS 12.

[AJPinto]

@sdagley The only thing I am seeing about software updates is 11.5 beta 3 fixes an issue that stops network extensions from loading after running updates. Is there something I missed?

@dgreening Agreed, but the main problem here is Apple does not see it as broken. It is working as intended. What really happened is Apple released an incomplete product, again... I have had a few conversations with Apples Engineers, and every time the question comes up they advise that Apple Silicon's M1 implantation is not intended for power users. M1 targeted at the general consumer. Apple really needs to add this to their marketing. Apple Silicon is not yet the end all be all they advertise it to be, this is really a public beta of what is to come and is still very much a work in progress. This work in progress state is why personally I think we have yet to see the higher end Mac Mini, MBP13 or MBP16 get updated to Apple Silicon. Those devices are their power user devices and Apple knows Apple Silicon is not ready for that market yet and Apple needs to be open about that.

[jtrant]

@sdagley I'm in the Developer program and AppleSeed for IT, but the developer page shows no release notes for 11.5 Beta 3. Am I missing something?

[snowfox]

Ben Toms from JamJar recently did a presentation on - Administering Apple Silicon devices

Ben Toms - Administering apple silicon

He describes how it's 'supposed' to work in a modern MDM. I have yet to see any of my ADE machines do this automatically. On 10.30.1, still no reduced security button ticked.

[sdagley]

@jtrant The changes I'm alluding to were in 11.5 Beta 2

[AJPinto]

@jtrant I believe that just added the ability to use the schedule an update remote command. Still does not offer anything in the way of user notification. How I understand it is the Mac just does its thing and once the updates are downloaded it reboots, or waits for the user to tell the Mac to do updates. No user notification of any sort. Also JAMF still has not added support for this. I am not beyond missing information, but this is how I understand it right now.

[dgreening]

@AJPinto Right you are that these new MDM commands and fixes to them are only as good as the JAMF implementation of them.

[abnaau]

Our Intel fleet: 99% of live devices upgraded. Using the softwareupdate command.

Our M1 fleet: 50% of live devices upgraded 😞 Using "Software Update" configuration profile with automatic updates "forced". Mass action updates don't work any better.   

I keep reading we can use bootstrap tokens to update but as far as I can see this is only the case if we GUI-login - not remotely. 

I'm losing my hair here.....

[mgorton]

Its amazing how unreliable it is on M1 Macs right now to manage updates.  I've tried numerous scripts from the community with limited success.

Anyone get anything to work reliably?

[andrew_betts]

We seem to have a workflow down that works for both M1 and intel- after exhausting every option.  We had nothing but problems with minor updates (policy, command, script etc) until we got all devices on 11.6 first.  Not sure what has changed, but complete nightmare running updates on 11.3 and 11.4.

Anyway, caching the full installer (11.6.1 as of today) is the only thing that consistently works.  We opted for sending out the installer in a policy as opposed to the fetch full installer command (is that even working these days?).  After sending out the installer, the basic startosinstall script works for intel devices, but a --passprompt or --stdinpass script is needed on M1s.  We go with --passprompt as we don't want to include the admin password in the script.  And it is after the update to 11.6 is complete that we then run the minor updates.  softwareupdate -iaR in a policy works on both M1s and Intels, but so does mass command.  Once again, neither seemed to work consistently before getting all the devices on 11.6.1.

And of course the accounts running all these updates have secureToken enabled on the logged in user and bootstrap token is supported and escrowed.

Have no intention of caching a full installer for every update, so curious to hear how things go with Monterey.

[pueo]

@andrew_betts Thanks for sharing your solution.  I'm guessing you are caching the full 12gig installer on each machine?  How do you deal with the remote workers on slower internet connections.  Does the full installer take out the users machine longer than the 20mins the 3gig installer does?  For us I can't see us pushing the installer out to our fleet.  I am using the softwareupdate cmd with -I -a -R --force and using jamf notifications giving users 48hrs to update themselves or at 7pm local time the device will update itself.  Emails, CHN request and documentation is submitted so users have plenty of notice.  Hopefully 12.x is better.

[andrew_betts]

Yep, full 12gig installer unfortunately. It hasn't been taking long, although staggering to only so many devices at a time.  We only cache it on prem so that we aren't using end user's at home data.  We do this by just changing the distribution point from default (cloud) to our on prem distribution point.  You could also change the client side limitation to business hours. 

The end users run the startosinstall script in SS at the time of their choosing so it doesn't interrupt anything.  And I haven't tried it yet, but could certainly throw the startosinstall into jamf helper for a little pomp & circumstance.

edit- looks like it takes us around 20 minutes to cache the full installer over wifi, but that is dealing with 5minute check in intervals, so it could actually be anywhere from 10-20 minutes.

[jlombardo]

Anyone else having a problem with this softwareupdate command on an M1?

sudo Softwareupdate --agree-to-license --force --restart --install 'macOS Big Sur 11.6.1-20G224'

I just started testing really, not sure if this works on the M1 or if we have to use softwareupdate -iaR... Seeing if anyone else already has knowledge on it.

[pueo]

Apply are moving away from the software update command for Silicon. I would try and use another method going forward.

[bwoods]

If you don't want to prompt the user at all, you can make a bash or python script that runs the Download and Install Updates management command for you. Add the script to a user interaction policy  to give the user the option to defer the update. 

apiUsername="apiaccount"
apiPassword="apipassword"
jamfProURL="https://yourorg.jamfcloud.com"
macSerial=$(system_profiler SPHardwareDataType | awk '/Serial Number/{print $4}')
jamfProCompID=$(curl -s -u $apiUsername:$apiPassword -H "Accept: text/xml" "$jamfProURL"/JSSResource/computers/serialnumber/"$macSerial" | xmllint --xpath '/computer/general/id/text()' -)


/usr/bin/curl -s -X POST -H "Content-Type: text/xml" -u ${apiUsername}:${apiPassword} ${jamfProURL}/JSSResource/computercommands/command/ScheduleOSUpdate/action/install/id/${jamfProCompID}

[fredrik_virding]

@bwoods 

Looks very promising.
Would the "Default" also be possible to switch to "InstallLater"?

[AJPinto]

I would recommend against doing this, but if you are going to do it you need to research salting the password. If you dont salt (encrypt) the password it will be going to devices in plane text and many savvy users know how to pull information from scripts. Unless you like the idea of users having your API Username and Password make sure to encrypt the password.

[bwoods]

@AJPinto there's a post here about encrypting the password for anyone interested. I'm interested to know why you wouldn't recommend doing this. I'm building a list of pros and cons before I put this into production.

@fredrik_virding I wasn't able to get the "Default" flag to work, but some people seem to have it working. Check out the hyperlink above. The OP is using that action.

[AJPinto]

its really just two reasons.

1. How JAMF manages API access is not very secure. You have to go out of your way to encrypt the password which is fine for those of us who are savvy. However many admins will not know how to do this properly. That and JAMFs access control sucks, if that API user and password get it it opens many doors. 

2. With how frustrating working with MDM commands is especially in relation to OS updates. This is not how Apple wants issuing MDM commands to work. So there is no telling when or if apple will break it. Also there are plenty of complications like you mentioned with default flag not working. 

To be honest, I am all about blazing a trail. Going where no documentation has gone before, going outside of the supported realm. However we are paying too much for JAMF to be having to do their job for them.

JAMF is supposedly working on making the work flow to issue these MDM commands from policy, but lord only knows when we will actually see it come to light.

https://community.jamf.com/t5/jamf-pro/managed-software-updates-using-deferrals-via-a-mass-action/td...