Posted on 08-02-2024 09:21 AM
I haven't used the Software Updates feature before. In the past, I have tried performing a mass action using a static group for testing. Yesterday, I decided to do that for some of my hot spares on the bench to take them from 14.5 to 14.6 and discovered that we had enabled the Software Updates feature. This understandably removed that ability from an action, so I figured I would give it a try with an eye towards deferrals as the "killer app" of the process.
We control updates on our active machines with some restrictions payload and restricted software, but the spares are a little more relaxed. The only thing they get is our software update payload, which is set to make sure updates are automatic and enabled:
So I decided to take two of them, put them in a static group and run the following:
This ran very much like previous experiences with the MDM action. Devices eventually handled the commands and downloading/staging commenced. I set one machine aside with the 'REBOOT(8)' man page open in a terminal window to prevent most restart methods from being successful. The other machine I sat and watched to confirm the softwareupdate/nsurl stuff. Watching logs, seeing snapshots in Disk Utility. All going to plan, but I never got the notification/deferral messages. Instead, the red number one appeared on the System Settings icon in the dock and that was it. There may be some notification voodoo here, but I am using the defaults and have received popups from softwareupdate in the past when the updates are automatically checked.
Completing the update on the watch machine worked great. I forced an inventory update just to see the OS correctly in Jamf. Here are the MDM commands in the period for the watched computer:
But now this is pending:
Things are the same on the set aside machine, which is still sitting at 14.5 with the red number one and no notifications. It has this history:
Still the same command pending. I'll eventually give up on the notifications and complete the update via System Settings UI. The questions I have are why are there no notifications for deferral when I specified that, and do I just need to cancel the pending MDM command or otherwise ignore it?
Solved! Go to Solution.
08-02-2024 09:32 AM - edited 08-02-2024 09:34 AM
from what I recall, deferred update still uses the old MDM method, which was kinda useless.
Use the scheduled update, this will prompt and force the update by the due date.
Check /var/db/softwareupdate for the SoftwareUpdateDDMStatePersistace.plist
there should be additional data in the devices record now on JAMF
08-02-2024 09:32 AM - edited 08-02-2024 09:34 AM
from what I recall, deferred update still uses the old MDM method, which was kinda useless.
Use the scheduled update, this will prompt and force the update by the due date.
Check /var/db/softwareupdate for the SoftwareUpdateDDMStatePersistace.plist
there should be additional data in the devices record now on JAMF
Posted on 08-02-2024 10:38 AM
Using the DDM scheduled update for iOS and macOS. Can confirm the notifications are working.
If you're set on the old deferral method, might be worth talking to Jamf Support...
Posted on 08-02-2024 12:45 PM
I ran another one:
Old MDM commands aren't sent like before. Instead only DeclarativeManagement is in the history. The Management tab looks encouragingly different:
The client notification appeared with the scheduled time and the options of Install or Try Tonight. I took some shots and then ignored it. The notification did disappear and isn't in the slideout history when you click the clock. It seems to have been replaced by the good old red number one, so thanks for the tips all. I also see the .plist file, which is pretty cool. Going to mark the issue solved, since scheduling seems to be the trick here.
Posted on 08-08-2024 01:31 PM
The computer did update to 14.6, so I shut it down and didn't think much of it. Then 14.6.1 came along, so I decided to use the process on some other spares. Things worked again, but then I noticed that the screenshot above is still there for the machine I took to 14.6 and shutdown about one day later. Has anyone else had the computers sit in "CollectingDDMStatus" with the Install state set to "Unknown"? The event store just shows a repetition of the "Unknown" state getting sent.
Posted on 08-09-2024 04:12 AM
Yes, this happened for me with iOS 17.6 and macOS 14.6. In my case, if I sent a new DDM for 17.6.1 or 14.6.1, the endpoints wouldn't take the new DDM. I had to clear the old one like in your screenshot.
To do this, I turned off the software update feature. Once the logs cleared, I turned it back on.
Posted on 08-09-2024 09:04 AM
Thanks for replying again. The 14.6 machine did end up showing "No updates in progress". The odd thing was that first the plan changed to 14.6.1, but I didn't send a plan for 14.6.1 to that computer. I did go into System Preferences on the 14.6 machine and kick off the 14.6.1 update, so that might have cleared it.
One thing that give me pause is that the computers that are stuck reporting that the plan is still running will not accept subsequent plans. I tried sending a second one and all the unstuck computers reported there were no updates available, which was the expected result. The stuck machines rejected it because they already have a plan running. Maybe it is something that shakes out in the next cycle like I saw with the 14.6 computer.
Either way, I can confirm that turning the feature off and then back on again does return the ability to send new plans and have them execute correctly on all computers. One thing that is inconvenient about that is that all the Operating System Management history is deleted, so while it is a decent workaround it may not be great for continued operations. Hopefully the feature gets better, since Security is definitely interested in anything that can help improve keeping macOS up to date.
Posted on 08-02-2024 11:43 AM
Thanks for the tip. I wondered if I was just holding it wrong by picking deferral, especially when it seemed to be much like to old MDM method. The OSUpdateStatus - Scheduled MDM commands are still pending. I didn't find anything in the operating system history under the history tab, but the operating system under the management tab looks like this on both the completed 14.6 and 14.5 computers:
I'll try the scheduled next time and see how that goes. For now I guess I will just cancel the pending MDM commands and see if they come back.
08-02-2024 12:06 PM - edited 08-02-2024 12:10 PM
not sure about the old MDM commands with NEW shiny Software Update (no longer beta!) but to reset it all, you just have to turn it off and on again. This will reset all the plans, so you can start again, or it should do.. everything will be fixed in macOS 15... 🤔🤠
That screen grab shows more information than before.. but every presentation has only ever mention scheduled updates.. and they work.. other than the forced reboot, which is kinda new for Mac people, it's progress.
Posted on 08-03-2024 08:26 AM
Why is the schedule install option only available for Jamf Cloud and not on-prem?
Posted on 08-03-2024 09:05 AM
Really irritates me that scheduling via DDM is not supported in Premium Cloud Plus.
Posted on 08-16-2024 07:03 AM
I've been trying this out recently on a couple of test machines and have noticed erratic results. For instance, user keeps getting notifications that an update is available.
If I go to Settings > General > Software Updates, it shows that OS is up-to date.
These are the settings I configured in Jamf Pro for the test group to trigger updates.
...and the operating system update menu for the Mac in question.
Having a hard time understanding why we are getting these alerts.
08-16-2024 07:14 AM - edited 08-16-2024 07:14 AM
the ghost update seems to be an intermittent issue with 14.6 / 14.6.1