Jamf Pro recommend using Mass Action Feature which can NOT be scheduled and KILL the network. I tried this on just 25 iMacs and my network was completed flooded and this was at night. It also worked on some and did not work on others. Very inconsistent.
the Policy running softwareupdates -i -a -R says is works in the logs but nothing happens as well. I can't believe the answer is to turn on Apple Automatic Updates or run manually.
Log in to Jamf Pro.
Click Computers at the top of the page.
Click Smart Computer Groups.
Select the name of the smart computer group you created.
Click View at the bottom of the pane.
Click Action at the bottom of the pane.
Select Send Remote Commands.
Click Next.
Under Remote Commands, select Update OS version and built-in apps (v10.11 or later computers enrolled with DEP only).
At the bottom of the pane, select one of the following for Update Action:
To download the update on computers for users to install themselves, select Download the update for users to install.
To download and install the update on computers automatically, select Download and install the update, and restart computers after installation.
I'm thinking it might be possible to schedule it using scripts. My current thought is to write a script to hit the API to get the computer ID and then hit the API again to send the Install updates command.
And it doesn't help at all that Apple released a patch for a 0-day and we admins have zero reliable ways to deploy said patch.
The MDM command seems to work but only really when a user is logged in? I thought I remember someone saying that a user had be to be logged in for the Download and install the update MDM command to work. Could someone confirm?
The MDM command seems to work but only really when a user is logged in? I thought I remember someone saying that a user had be to be logged in for the Download and install the update MDM command to work. Could someone confirm?
And I just tried this yesterday, and it prompted for my user password before it installed..
I have spent the last couple of days working with a colleague testing out various methods of trying to update Big Sur on our Intel iMacs since we noticed that the Software Update payload policy we had setup was doing nothing. These are iMacs in a higher education shared lab environment where our users are not logged on at the time we would like to action updates (ideally run automatically overnight).
We have tried the following...
- Deploying the ‘softwareupdate -i -a -R’ command as a script via a policy in Jamf which was the initially advised workaround by Jamf Support. This was unsuccessful.
- Deploying the ‘softwareupdate -i -a -R’ command in the Files & Processes payload in a Jamf policy. This was suggested by Jamf Support during a support call and we are advised this is the working “workaround”. From the logs this states that it completes and from the log details looks successful as it downloads the latest update and advises it’s restarting but this is actually a false positive the restart never occurs. The update downloads but the restart does not occur unless a user is logged in at the time the policy runs. The only way to kick off the update is by logging in and restarting manually from either software updates or running the ‘softwareupdate -i -a -R’ command in the terminal.
- Deploying an additional policy with the Restart Options payload configured to ‘Restart if a package or update requires it’ and is set like this for both the No User Logged In Action and User Logged In Action. Hoping that with the software update being downloaded to the machine this would issue a restart and install the update that requires it. This did not work.
- Deploying an additional policy with the Restart Options payload configured to ‘Restart Immediately’ for both the No User Logged In Action and User Logged In Action. Again hoping that the restart would trigger the installation of the downloaded update. It did not.
- Resetting the NVRAM of some of the devices and trying to deploy the ‘softwareupdate -i -a -R’ command in the Files & Processes payload again. This was a bit of a shot in the dark but seeing some other admins advise that their devices were stuck on the black screen with the Apple logo looking like it was installing and doing this resolved it and installed the update. The Macs still would not restart automatically and required a user to be logged in.
It is pretty clear that updates for Big Sur cannot be managed automatically without some user involvement. On intel Macs a user needs to be logged in for Jamf's advised workaround (I use this term loosely...) of using the 'softwareupdate -i -a -R' command. M1 devices are another kettle of fish that we are going to have to deal with soon as well.
This is quite ridiculous to say the least. This OS came out 8+ months ago with advertised zero-day support yet here we are. Surely we can't be the only higher education organisation that will have to stick with macOS Catalina for the start of term unless we can get a working solution.
I have spent the last couple of days working with a colleague testing out various methods of trying to update Big Sur on our Intel iMacs since we noticed that the Software Update payload policy we had setup was doing nothing. These are iMacs in a higher education shared lab environment where our users are not logged on at the time we would like to action updates (ideally run automatically overnight).
We have tried the following...
- Deploying the ‘softwareupdate -i -a -R’ command as a script via a policy in Jamf which was the initially advised workaround by Jamf Support. This was unsuccessful.
- Deploying the ‘softwareupdate -i -a -R’ command in the Files & Processes payload in a Jamf policy. This was suggested by Jamf Support during a support call and we are advised this is the working “workaround”. From the logs this states that it completes and from the log details looks successful as it downloads the latest update and advises it’s restarting but this is actually a false positive the restart never occurs. The update downloads but the restart does not occur unless a user is logged in at the time the policy runs. The only way to kick off the update is by logging in and restarting manually from either software updates or running the ‘softwareupdate -i -a -R’ command in the terminal.
- Deploying an additional policy with the Restart Options payload configured to ‘Restart if a package or update requires it’ and is set like this for both the No User Logged In Action and User Logged In Action. Hoping that with the software update being downloaded to the machine this would issue a restart and install the update that requires it. This did not work.
- Deploying an additional policy with the Restart Options payload configured to ‘Restart Immediately’ for both the No User Logged In Action and User Logged In Action. Again hoping that the restart would trigger the installation of the downloaded update. It did not.
- Resetting the NVRAM of some of the devices and trying to deploy the ‘softwareupdate -i -a -R’ command in the Files & Processes payload again. This was a bit of a shot in the dark but seeing some other admins advise that their devices were stuck on the black screen with the Apple logo looking like it was installing and doing this resolved it and installed the update. The Macs still would not restart automatically and required a user to be logged in.
It is pretty clear that updates for Big Sur cannot be managed automatically without some user involvement. On intel Macs a user needs to be logged in for Jamf's advised workaround (I use this term loosely...) of using the 'softwareupdate -i -a -R' command. M1 devices are another kettle of fish that we are going to have to deal with soon as well.
This is quite ridiculous to say the least. This OS came out 8+ months ago with advertised zero-day support yet here we are. Surely we can't be the only higher education organisation that will have to stick with macOS Catalina for the start of term unless we can get a working solution.
Thank you for your detailed account of exactly what is happening in our
environment as well.
--
Debbie Michels
Apple Specialist
ITS Information Technology Services
Bergen Community College
Pitkin Building - Room A236
400 Paramus Road, Paramus NJ 07652
dmichels@bergen.edu
(O) 201-879-1694
*STAFF/FACULTY* Working Remotely Instructions at Bergen:
https://bergen.edu/REMOTE*STUDENTS* Self Service
https://bergen.edu/self-service/
I have spent the last couple of days working with a colleague testing out various methods of trying to update Big Sur on our Intel iMacs since we noticed that the Software Update payload policy we had setup was doing nothing. These are iMacs in a higher education shared lab environment where our users are not logged on at the time we would like to action updates (ideally run automatically overnight).
We have tried the following...
- Deploying the ‘softwareupdate -i -a -R’ command as a script via a policy in Jamf which was the initially advised workaround by Jamf Support. This was unsuccessful.
- Deploying the ‘softwareupdate -i -a -R’ command in the Files & Processes payload in a Jamf policy. This was suggested by Jamf Support during a support call and we are advised this is the working “workaround”. From the logs this states that it completes and from the log details looks successful as it downloads the latest update and advises it’s restarting but this is actually a false positive the restart never occurs. The update downloads but the restart does not occur unless a user is logged in at the time the policy runs. The only way to kick off the update is by logging in and restarting manually from either software updates or running the ‘softwareupdate -i -a -R’ command in the terminal.
- Deploying an additional policy with the Restart Options payload configured to ‘Restart if a package or update requires it’ and is set like this for both the No User Logged In Action and User Logged In Action. Hoping that with the software update being downloaded to the machine this would issue a restart and install the update that requires it. This did not work.
- Deploying an additional policy with the Restart Options payload configured to ‘Restart Immediately’ for both the No User Logged In Action and User Logged In Action. Again hoping that the restart would trigger the installation of the downloaded update. It did not.
- Resetting the NVRAM of some of the devices and trying to deploy the ‘softwareupdate -i -a -R’ command in the Files & Processes payload again. This was a bit of a shot in the dark but seeing some other admins advise that their devices were stuck on the black screen with the Apple logo looking like it was installing and doing this resolved it and installed the update. The Macs still would not restart automatically and required a user to be logged in.
It is pretty clear that updates for Big Sur cannot be managed automatically without some user involvement. On intel Macs a user needs to be logged in for Jamf's advised workaround (I use this term loosely...) of using the 'softwareupdate -i -a -R' command. M1 devices are another kettle of fish that we are going to have to deal with soon as well.
This is quite ridiculous to say the least. This OS came out 8+ months ago with advertised zero-day support yet here we are. Surely we can't be the only higher education organisation that will have to stick with macOS Catalina for the start of term unless we can get a working solution.
Thank you for your detailed account of exactly what is happening in our environment as well. It has been too long for there not to be working fix.
And I just tried this yesterday, and it prompted for my user password before it installed..
Was this on an Intel or M1 Mac?
I'm thinking it might be possible to schedule it using scripts. My current thought is to write a script to hit the API to get the computer ID and then hit the API again to send the Install updates command.
And it doesn't help at all that Apple released a patch for a 0-day and we admins have zero reliable ways to deploy said patch.
#!/bin/bash
# Variables used by Casper
USERNAME="" #Username of user with API Computer read GET and Computer Group PUT access
PASSWORD="" #Password of user with API Computer read GET and Computer Group PUT access
JSS_URL='https://jss.my.com:8443' # JSS URL of the server you want to run API calls against
Headers="Accept: application/xml"
# Variables used by this script
JSS_ID_PATH="/tmp/comp_id" # Text file with one JSS ID per Line
IFS_OLD=$IFS
IFS_TEMP=$'\\n'
IFS=$IFS_TEMP
## Functions
####################################################################################################
# Include DecryptString() with your script to decrypt the password sent by the JSS
# The 'Salt' and 'Passphrase' values would be present in the script
function DecryptString() {
# Usage: ~$ DecryptString "Encrypted String" "Salt" "Passphrase"
PASSWORD=$(echo "${1}" | /usr/bin/openssl enc -aes256 -d -a -A -S "${2}" -k "${3}")
}
function GetComputerID() {
# Get the computer ID
SERIAL=`system_profiler SPHardwareDataType | awk '/Serial/ {print $4}'`
URL="https://jss.my.com:8443/JSSResource/computers/serialnumber/$SERIAL"
RESPONSE=$(/usr/bin/curl -H "$Headers" -u "$USERNAME:$PASSWORD" --url $URL) > /dev/null
JamfId=$(echo $RESPONSE | xpath -e '//computer//general/id' 2>&1 | awk -F'<id>|</id>' '{print $2}') > /dev/null
/usr/bin/defaults write /Library/Preferences/com.my.systeminfo JamfId "$JamfId"
echo "$JamfId" > /tmp/comp_id
}
# This uploads the $JSS_XML_INPUT file to the JSS
function RunMDMCommand() {
curl -k -v -H "$Headers" -u "$USERNAME":"$PASSWORD" "$JSS_URL/JSSResource/computercommands/command/ScheduleOSUpdate/action/install/id/$JamfId" -X POST > /dev/null
echo "$?"
echo "Done"
}
function CleanUp() {
rm $JSS_ID_PATH
}
## Script
####################################################################################################
# Script Action 1
ENCRYPTEDSTRING="$4"
SALT=""
PASSPHRASE=""
DecryptString "$ENCRYPTEDSTRING" "$SALT" "$PASSPHRASE"
GetComputerID
RunMDMCommand
CleanUpI'm trying out this script I wrote/rewrote to see if it will handle reboots too.
Has anyone tried this yet?
https://docs.jamf.com/best-practice-workflows/jamf-pro/managing-macos-updates/Running_Software_Update_Using_a_Policy.html
It seems to work with Catalina, but I'm not sure if it works with Big Sur.
This does not work.
--
Debbie Michels
Apple Specialist
ITS Information Technology Services
Bergen Community College
Pitkin Building - Room A236
400 Paramus Road, Paramus NJ 07652
dmichels@bergen.edu
(O) 201-879-1694
*STAFF/FACULTY* Working Remotely Instructions at Bergen:
https://bergen.edu/REMOTE*STUDENTS* Self Service
https://bergen.edu/self-service/
This does not work.
--
Debbie Michels
Apple Specialist
ITS Information Technology Services
Bergen Community College
Pitkin Building - Room A236
400 Paramus Road, Paramus NJ 07652
dmichels@bergen.edu
(O) 201-879-1694
*STAFF/FACULTY* Working Remotely Instructions at Bergen:
https://bergen.edu/REMOTE
*STUDENTS* Self Service
https://bergen.edu/self-service/
You are correct this no longer works for Intel based Macs running macOS 11 Big Sur any version.
Are MDM update commands in Big Sur unreliable?
I tried sending an MDM command to an 11.4 Big Sur Mac to download update, install and restart but while it seemed to download from the management history, and it even rebooted, nothing occurred (still at 11.4 instead fo 11.5). Nobody was logged into this machine.
Any suggestions?
I think in the end we are going to try to simply try to enforce check updates on our Macs but provide a deferral period.
So basically we are going to take the Apple shipping default below
Apply a Configuration Profile
Which will enforce all settings including installing macOS updates
This will auto download and will initially just notify a user that there is an update available and whether they want to install now or later.
If they ignore this message then a day or two later the computer will simply alert them that the update will install later that night.
Though if they have any unsaved worked it will stop the reboot process so there is safety for that.
Next time they try to restart the computer the update will finally apply.
For additional safety a Defer Update Configuration Profile can be used. This one below is set for 15 days.
I didn't want to use the built in Restrictions Config Profile from Jamf since it has too many settings.
So @takayuki helped me with this part to create a custom one that only does the defer update.
Seems to work well on Big Sur Intel though I haven't tried to see what the behavior is on M1
This is a long thread, and I've been following along as well with multiple bags of popcorn...
It looks like there's a bug in Big Sur where the softwareupdate tool will not execute a restart if a user is not logged into the system. I've been playing around with softwareupdate commands using --verbose and the output is quite different when executed with a user logged in versus when a user is not logged in. It looks like a lot of changes to softwareupdate were made under the hood to accommodate Apple Silicon based OS update processes which operate more like iOS than previous versions of macOS thanks to differences in lineage. I don't think this is by design, but since we're at version 11.5 at this point and Monterey 12.0 is around the corner, probably not worth going through the effort to open a support ticket with Apple support about this.
In any event, I think I've gotten around this for the labs I manage by creating a combination of policies that during our maintenance windows overnight, will boot our systems automatically with an account setup for automatic login, then runs a policy to run softwareupdate and install and download all updates. That softwareupdate script also removes the automatic login flag so that at next restart after the updates it's back at the normal login window.
I'm still testing this, so I'm hesitant to post any script/code examples yet, but figured I would just post this as a more "thinking in writing" kind of post for anyone else that's stumped on how to push these updates reliably to computer lab like scenarios where there won't be someone in front of the keyboard and mouse to say yes.
This is a long thread, and I've been following along as well with multiple bags of popcorn...
It looks like there's a bug in Big Sur where the softwareupdate tool will not execute a restart if a user is not logged into the system. I've been playing around with softwareupdate commands using --verbose and the output is quite different when executed with a user logged in versus when a user is not logged in. It looks like a lot of changes to softwareupdate were made under the hood to accommodate Apple Silicon based OS update processes which operate more like iOS than previous versions of macOS thanks to differences in lineage. I don't think this is by design, but since we're at version 11.5 at this point and Monterey 12.0 is around the corner, probably not worth going through the effort to open a support ticket with Apple support about this.
In any event, I think I've gotten around this for the labs I manage by creating a combination of policies that during our maintenance windows overnight, will boot our systems automatically with an account setup for automatic login, then runs a policy to run softwareupdate and install and download all updates. That softwareupdate script also removes the automatic login flag so that at next restart after the updates it's back at the normal login window.
I'm still testing this, so I'm hesitant to post any script/code examples yet, but figured I would just post this as a more "thinking in writing" kind of post for anyone else that's stumped on how to push these updates reliably to computer lab like scenarios where there won't be someone in front of the keyboard and mouse to say yes.
I am very interested in where you're going with this. Please keep us updated!
I am very interested in where you're going with this. Please keep us updated!
I did more testing after I posted and it seems to be working as I hoped. I'll post more details when I get a chance. The basic requirements:
- A script, executed by a policy, that writes the proper values to allow an account to automatically login at next restart. The policy also executes a restart at the end of the policy run.
- A script, executed by a policy to run at startup, once per day, to execute the software update command when the system is logged in. This script also removes the auto-login values so that after software updates run, the system is back to booting to a login window. The policy also has a reboot built-in, in the event no updates are found, so the softwareupdate tool doesn't force the restart first.
So far this has worked with two of my labs pretty well. These are Intel iMacs. I don't believe this scheme will not work for M1 Macs - but I don't have any of those in a managed lab setting yet.
I have spent the last couple of days working with a colleague testing out various methods of trying to update Big Sur on our Intel iMacs since we noticed that the Software Update payload policy we had setup was doing nothing. These are iMacs in a higher education shared lab environment where our users are not logged on at the time we would like to action updates (ideally run automatically overnight).
We have tried the following...
- Deploying the ‘softwareupdate -i -a -R’ command as a script via a policy in Jamf which was the initially advised workaround by Jamf Support. This was unsuccessful.
- Deploying the ‘softwareupdate -i -a -R’ command in the Files & Processes payload in a Jamf policy. This was suggested by Jamf Support during a support call and we are advised this is the working “workaround”. From the logs this states that it completes and from the log details looks successful as it downloads the latest update and advises it’s restarting but this is actually a false positive the restart never occurs. The update downloads but the restart does not occur unless a user is logged in at the time the policy runs. The only way to kick off the update is by logging in and restarting manually from either software updates or running the ‘softwareupdate -i -a -R’ command in the terminal.
- Deploying an additional policy with the Restart Options payload configured to ‘Restart if a package or update requires it’ and is set like this for both the No User Logged In Action and User Logged In Action. Hoping that with the software update being downloaded to the machine this would issue a restart and install the update that requires it. This did not work.
- Deploying an additional policy with the Restart Options payload configured to ‘Restart Immediately’ for both the No User Logged In Action and User Logged In Action. Again hoping that the restart would trigger the installation of the downloaded update. It did not.
- Resetting the NVRAM of some of the devices and trying to deploy the ‘softwareupdate -i -a -R’ command in the Files & Processes payload again. This was a bit of a shot in the dark but seeing some other admins advise that their devices were stuck on the black screen with the Apple logo looking like it was installing and doing this resolved it and installed the update. The Macs still would not restart automatically and required a user to be logged in.
It is pretty clear that updates for Big Sur cannot be managed automatically without some user involvement. On intel Macs a user needs to be logged in for Jamf's advised workaround (I use this term loosely...) of using the 'softwareupdate -i -a -R' command. M1 devices are another kettle of fish that we are going to have to deal with soon as well.
This is quite ridiculous to say the least. This OS came out 8+ months ago with advertised zero-day support yet here we are. Surely we can't be the only higher education organisation that will have to stick with macOS Catalina for the start of term unless we can get a working solution.
@jamfjosh21 "This OS came out 8+ months ago with advertised zero-day support yet here we are." Lets not forget that the ScheduleOSUpdates management commands were originally put in macOS 10.11, not macOS 11. Apple and JAMF have had 6 years at this point to get them working and have failed to do so.
I am sure this is more of a problem on Apples side than JAMFs, but JAMF has actively avoided doing anything with macOS updates so far. Apple should have never killed the softwareupdate terminal commands functionality before getting ScheduleOSUpdates working right. Apple is so desperate to get Macs to function like iOS devices that they are not making sure things work before making changes. Apples QA is really garbage right now.
This is a long thread, and I've been following along as well with multiple bags of popcorn...
It looks like there's a bug in Big Sur where the softwareupdate tool will not execute a restart if a user is not logged into the system. I've been playing around with softwareupdate commands using --verbose and the output is quite different when executed with a user logged in versus when a user is not logged in. It looks like a lot of changes to softwareupdate were made under the hood to accommodate Apple Silicon based OS update processes which operate more like iOS than previous versions of macOS thanks to differences in lineage. I don't think this is by design, but since we're at version 11.5 at this point and Monterey 12.0 is around the corner, probably not worth going through the effort to open a support ticket with Apple support about this.
In any event, I think I've gotten around this for the labs I manage by creating a combination of policies that during our maintenance windows overnight, will boot our systems automatically with an account setup for automatic login, then runs a policy to run softwareupdate and install and download all updates. That softwareupdate script also removes the automatic login flag so that at next restart after the updates it's back at the normal login window.
I'm still testing this, so I'm hesitant to post any script/code examples yet, but figured I would just post this as a more "thinking in writing" kind of post for anyone else that's stumped on how to push these updates reliably to computer lab like scenarios where there won't be someone in front of the keyboard and mouse to say yes.
We have already made the call to skip Apple Silicon on Big Sur. It is really not a finished product. Things like the forceDelayedSoftwareUpdates and enforcedSoftwareUpdateDelay keys for the ScheduleOSUpdates policy not being added until Monterey despite Apple breaking any way to do this with softwareupdate on Apple Silicon is just proof apple is releasing incomplete products. We have not had any reliable luck on getting OS updates to work on Apple Silicon. They will run with the Management command, but when they run is totally in the air. Also the Management command not canning a FileVault approval is making lab testing really annoying while remote.
I honestly think Apple Silicon was released before it was ready, probably Apple trying to get back at Intel.
We have already made the call to skip Apple Silicon on Big Sur. It is really not a finished product. Things like the forceDelayedSoftwareUpdates and enforcedSoftwareUpdateDelay keys for the ScheduleOSUpdates policy not being added until Monterey despite Apple breaking any way to do this with softwareupdate on Apple Silicon is just proof apple is releasing incomplete products. We have not had any reliable luck on getting OS updates to work on Apple Silicon. They will run with the Management command, but when they run is totally in the air. Also the Management command not canning a FileVault approval is making lab testing really annoying while remote.
I honestly think Apple Silicon was released before it was ready, probably Apple trying to get back at Intel.
100%
I'm glad to know that I'm not the only one struggling with macOS patch management.
Has anyone tried using Nudge + M1? Or is another hair pulling experience?
I haven't done any M1 testing yet, I have 1 test macbook which is due to come out of the cellophane this week but that's in advance of hundreds of M1 iMacs turning up so I need to crack on with it.
I see in the release notes for 10.31 is says that you can reboot an M1 mac using a management command from within the policy which removes the need for authentication. It seems to be suggesting that if you make a policy which does the jamf updates payload followed by that it should work?
Has anyone tried this and if it's not working where does that fall over? I'm guessing the management command might not always work. Also if they release M1 MBPs which still have a touch bar (I wouldn't be sad to see them get rid of it I don't see the point) I wonder if the management command would know when to do the shutdown rather than reboot if needed.
I haven't done any M1 testing yet, I have 1 test macbook which is due to come out of the cellophane this week but that's in advance of hundreds of M1 iMacs turning up so I need to crack on with it.
I see in the release notes for 10.31 is says that you can reboot an M1 mac using a management command from within the policy which removes the need for authentication. It seems to be suggesting that if you make a policy which does the jamf updates payload followed by that it should work?
Has anyone tried this and if it's not working where does that fall over? I'm guessing the management command might not always work. Also if they release M1 MBPs which still have a touch bar (I wouldn't be sad to see them get rid of it I don't see the point) I wonder if the management command would know when to do the shutdown rather than reboot if needed.
The ScheduleOSUpdates management command is self contained. I am not sure if an external reboot from any source whether it be another management command or scripted would trigger updates to run. With 10.29 (I think) JAMF changed the default action on ScheduleOSUpdates to install ASAP (I forget what the key is). We are still running JAMF 10.26 so I have not tested that yet.
However any enforcement of macOS updates will come with Monterey, however I am still not sure how reliable that will be. If the Mac does not get the command, or something borks in the command I bet updates still wont run regardless what you set the Management Command to do. Lord only knows when JAMF will update to add all the new keys and features for ScheduleOSUpdates, I am figuring 1st quarter next year. I very highly doubt it will be with their day 1 "support" of macOS Monterey which we wall know is just sales talk.
Only One M1 MacBook to test on before an entire fleet of M1 iMacs. Yikes. I have had a MacBook Air and 2x Mac Mini's to test with since January and this is still a mess. Apple Silicon and managing updates is a total mess. If you have not tinkered with Apple Silicon at all, look in to queueing Rosetta to install via script; odds are you will need Rosetta.
I'm glad to know that I'm not the only one struggling with macOS patch management.
Has anyone tried using Nudge + M1? Or is another hair pulling experience?
Nudge will nag your end users to update but it is up to them to click Install. I'm doing a similar thing using OSUpdateNotifier.sh.
The ScheduleOSUpdates management command is self contained. I am not sure if an external reboot from any source whether it be another management command or scripted would trigger updates to run. With 10.29 (I think) JAMF changed the default action on ScheduleOSUpdates to install ASAP (I forget what the key is). We are still running JAMF 10.26 so I have not tested that yet.
However any enforcement of macOS updates will come with Monterey, however I am still not sure how reliable that will be. If the Mac does not get the command, or something borks in the command I bet updates still wont run regardless what you set the Management Command to do. Lord only knows when JAMF will update to add all the new keys and features for ScheduleOSUpdates, I am figuring 1st quarter next year. I very highly doubt it will be with their day 1 "support" of macOS Monterey which we wall know is just sales talk.
Only One M1 MacBook to test on before an entire fleet of M1 iMacs. Yikes. I have had a MacBook Air and 2x Mac Mini's to test with since January and this is still a mess. Apple Silicon and managing updates is a total mess. If you have not tinkered with Apple Silicon at all, look in to queueing Rosetta to install via script; odds are you will need Rosetta.
I don't think they're suggesting you can do the MDM install via a policy, just the reboot part? This is what the notes say:
You can now create a policy to use the RestartDevice MDM command to restart computers in your environment. This includes the option to rebuild the kernel cache with specific kernel extension (kext) paths.
To use the RestartDevice MDM command, create a policy with a Restart Options payload. If you want to rebuild the kernel cache, select MDM Restart with Kernel Cache Rebuild and specify the kext paths.
Computers with Apple Silicon (i.e., M1 chip) must have a Bootstrap token escrowed to Jamf Pro in order to leverage this command. Computers running a version of macOS prior to 11.0 cannot leverage the the kernel cache rebuild functionality of the RestartDevice MDM command.
I take that to mean you'd have a policy which says
1) install all SWUs
2) Reboot
and then the reboot bit would use an MDM command if it knew the computer was an M1? I may be totally wrong though!
And I am very late with starting the M1 testing yes, things have been quite up in the air still due to COVID and being in education we've been unsure exactly what we'd be buying and so on.
I don't think they're suggesting you can do the MDM install via a policy, just the reboot part? This is what the notes say:
You can now create a policy to use the RestartDevice MDM command to restart computers in your environment. This includes the option to rebuild the kernel cache with specific kernel extension (kext) paths.
To use the RestartDevice MDM command, create a policy with a Restart Options payload. If you want to rebuild the kernel cache, select MDM Restart with Kernel Cache Rebuild and specify the kext paths.
Computers with Apple Silicon (i.e., M1 chip) must have a Bootstrap token escrowed to Jamf Pro in order to leverage this command. Computers running a version of macOS prior to 11.0 cannot leverage the the kernel cache rebuild functionality of the RestartDevice MDM command.
I take that to mean you'd have a policy which says
1) install all SWUs
2) Reboot
and then the reboot bit would use an MDM command if it knew the computer was an M1? I may be totally wrong though!
And I am very late with starting the M1 testing yes, things have been quite up in the air still due to COVID and being in education we've been unsure exactly what we'd be buying and so on.
I am talking about Intel chips, not M1 chips. I know we have to boot M1s manually, however, since upgrading to Big Sur on Intel Chip iMacs I also have to boot manually which is not how it is suppose to work. Jamf should have resolved this issue by now.
I am talking about Intel chips, not M1 chips. I know we have to boot M1s manually, however, since upgrading to Big Sur on Intel Chip iMacs I also have to boot manually which is not how it is suppose to work. Jamf should have resolved this issue by now.
Apple changed a lot of things with softwareupdates between 10.14 and 11.1. JAMF needs an escrowed bootstrap token to run software updates for one. There are also dependencies on the version of JAMF you are running. If you are using mobile accounts that do not have admin access they will not have a secure token to approve updates. My guess is something is off with your environment and configuration. Have you opened a ticket with JAMF?
Using a script to run software updates is functionally no different than typing the commands in to terminal. The only real difference is authentication, does your JAMF instance have the bootstrap token for all your Macs to tell macOS to run updates. I am assuming you dont have some random SSL redirection/inspection tool like Forcepoint or Netskope doing inspections and redirections which will kill Apple packets.
I agree JAMF should have dome something formal a long time ago with MacOS updates by policy. However, Apple has killed macOS updates by policy so there is no sense in JAMF developing this channel any further at this point in time. That ugly Management Command is the future and where I would spend my effort figuring things out.
