Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Configuration Profiles Keep "Rolling" Deferrals #250

Open
majorsl opened this issue Nov 1, 2024 · 18 comments
Open

Configuration Profiles Keep "Rolling" Deferrals #250

majorsl opened this issue Nov 1, 2024 · 18 comments
Labels
question Further information is requested

Comments

@majorsl
Copy link

majorsl commented Nov 1, 2024

I noted that my test Sequoia machine should have received the 15.1 update by now. So, I started watching a few days ago.

We have a configuration profile via Intune that defers minor updates for 2 days.

TWO days ago Super said:
Restrictions Deferral: macOS minor update 1 of 1 is: DeferredUntil:2024-11-01 00:00:00,Title:macOS Sequoia 15.1,Build:24B83,Version:15.1

I just ran it NOW, 2 days later, and should have been offered 15.1. Instead:
Restrictions Deferral: macOS minor update 1 of 1 is: DeferredUntil:2024-11-03 00:00:00,Title:macOS Sequoia 15.1,Build:24B83,Version:15.1

It just bumped it 2 more days?! I have a feeling this has been happening since it was available.

Ideas? Log below.

 
Fri Nov 01 19:41:16 MAC40400 super[77565]: **** S.U.P.E.R.M.A.N. 5.0.0 - SUPER STARTUP **** Fri Nov 01 19:41:17 MAC40400 super[77565]: Status: Mac computer with Apple silicon running: macOS Sequoia 15.0.1-24A348 Fri Nov 01 19:41:17 MAC40400 super[77565]: Status: Last macOS startup was: 2024-10-11:09:56:43 Fri Nov 01 19:41:17 MAC40400 super[77565]: Status: Current active GUI user is: testmac (1714728167) Fri Nov 01 19:41:17 MAC40400 super[77565]: Warning: Automatic download of macOS updates is currently enabled, this can result in updates being downloaded outside of super workflows. Fri Nov 01 19:41:19 MAC40400 super[77565]: Status: macOS update/upgrade workflows automatically authenticated via saved local account. Fri Nov 01 19:41:19 MAC40400 super[77565]: **** S.U.P.E.R.M.A.N. 5.0.0 - CHECK FOR SOFTWARE UPDATES/UPGRADES **** Fri Nov 01 19:41:19 MAC40400 super[77565]: Status: Restrictions configuration profile is deferring macOS major upgrades for 45 days. Fri Nov 01 19:41:19 MAC40400 super[77565]: Status: Restrictions configuration profile is deferring macOS minor updates for 2 days. Fri Nov 01 19:41:19 MAC40400 super[77565]: Status: Restrictions configuration profile is deferring non-system updates for 1 days. Fri Nov 01 19:41:19 MAC40400 super[77565]: Status: Some updates are deferred due to a restrictions deferral configuration profile. Fri Nov 01 19:41:19 MAC40400 super[77565]: Restrictions Deferral: macOS minor update 1 of 1 is: DeferredUntil:2024-11-03 00:00:00,Title:macOS Sequoia 15.1,Build:24B83,Version:15.1 Fri Nov 01 19:41:19 MAC40400 super[77565]: Status: No currently available macOS software updates due to software update deferral restrictions configuration profile. Fri Nov 01 19:41:20 MAC40400 super[77565]: Status: Resetting any workflow dates. Fri Nov 01 19:41:20 MAC40400 super[77565]: Status: Resetting any deadline counters. Fri Nov 01 19:41:20 MAC40400 super[77565]: Status: Full super workflow complete! The super workflow is scheduled to automatically relaunch in 360 minutes. Fri Nov 01 19:41:20 MAC40400 super[77565]: Exit: super is scheduled to automatically relaunch at: 2024-11-02:01:41:00 Fri Nov 01 19:41:20 MAC40400 super[77565]: **** S.U.P.E.R.M.A.N. 5.0.0 - EXIT CLEAN ****

@ofirgalcon
Copy link

I'm seeing the same behaviour. I use a config profile to set the deadline at 7 days after the client detects the update.

I have one client that was set to update by Oct 31, now the zero-date and deadline have been reset to Nov 2 and Nov 9. This client is still on 14.5.0. I can't access the logs, but it looks like superman has been rolling the dates into the future and never forcing an update.

@majorsl
Copy link
Author

majorsl commented Nov 4, 2024

I just checked a Mac in one of our other areas where we are ready for Sonoma. We have major OS updates delayed for 45 days. It actually seems to have rolled that into late December.

@Macjutsu Macjutsu added the question Further information is requested label Nov 4, 2024
@Macjutsu
Copy link
Owner

Macjutsu commented Nov 4, 2024

To be clear... super does NOT determine the deferral date... the system does.

super is simply reacting to the output of the mdmclient command. I've updated the wiki with more detail... but basically these dates come from the system... not super.

https://github.com/Macjutsu/super/wiki/Troubleshooting#mdmclient-listlog

I'll leave this open for now, but I suspsect there isn't anything wrong with super as it's just getting those dates from the mdmclient command.

@ofirgalcon
Copy link

In my case the deferral is 18 days, but these clients have missed on several updates as they keep resetting their zero date. It's very hard to follow, so I wrote a MunkiReport module to help track things, based around the Jamf EAs

image image

This client is still at 14.5.0

@majorsl
Copy link
Author

majorsl commented Nov 4, 2024

Interesting... I have a group with Sequoia approved. Digging into it a little more, some are not getting their deferrals rolled - yet being in the same group they should all have identical config profiles.

@Macjutsu
Copy link
Owner

Macjutsu commented Nov 5, 2024

Just to make sure you are aware... the default behavior of super's zero day is based on when super first found an update.... not the actual zero day of the update's release.

https://github.com/Macjutsu/super/wiki/Workflow-Schedule-Behavior
https://github.com/Macjutsu/super/wiki/Workflow-Schedule-Behavior#schedule-zero-date-macos-release

@ofirgalcon
Copy link

Yes that's exactly what I want, install 7 days after discovering the update. It seems that's where the issue is, it keeps on 're-discovering'

@Macjutsu
Copy link
Owner

Macjutsu commented Nov 5, 2024

I would have to see the full super.log of a device that is affected.

However, if you want the MOST consistent behavior then use --schedule-zero-date-release and then adjust your deadlines accordingly. Further, this should work in conjunction with your deferral restrictions config profile. For example, if you are deferring updates for 18 days... then super shouldn't start prompting untill that deferral is expired. Then set your super deadline for 18+7 days instead of just 7.

@ofirgalcon
Copy link

I wanted to but what happens if a user is away and returns past the deadline? does the computer force an update straight away?

@majorsl
Copy link
Author

majorsl commented Nov 5, 2024

I wanted to but what happens if a user is away and returns past the deadline? does the computer force an update straight away?

Good question! I might do that as well. In my mind, it would/should start a 7 day deferral option at that point, from a cyber security standpoint, it isn't my employer's problem if someone was away while a potentially critical update became available and it should be applied asap.

@ofirgalcon
Copy link

I agree but there should be a grace period. Some of the users only open their laptop 5 minutes before a zoom call and then shut it down for days. Under the SOFA scenario it will start to update and they wont be able to stop it just before a meeting.

@iDrewbs
Copy link

iDrewbs commented Nov 5, 2024 via email

@majorsl
Copy link
Author

majorsl commented Nov 5, 2024

You can always set the timer for the dialog to an extended period, a several hours perhaps, so in that scenario if they started a zoom call they wouldn’t need to restart right away.

I'm actually testing this right now. You all inspired me.

@I-Wildcard
Copy link

I-Wildcard commented Nov 14, 2024

Hi all,

I believe I see an issue that might be related to this thread.

We are planning to move from a 7-day deferral to a 14-day deferral for minor updates, with a 7-day deadline for completing the update, making it 14+7 in total.

I am testing Super by performing an update from macOS Sequoia 15.0.1 to 15.1.
Everything works correctly with the original 7-day deferral: the deferral has expired, and the Super workflow starts as expected, downloading and preparing the update before prompting the user.

However, when switching to a 14-day deferral, I’m observing the following:

Wed Nov 13 10:47:27 hostname super-starter[5050]: **** S.U.P.E.R.M.A.N. 5.0.0 - LAUNCHDAEMON ****\
Wed Nov 13 10:47:27 hostname super[5099]: **** S.U.P.E.R.M.A.N. 5.0.0 - SUPER STARTUP ****\
Wed Nov 13 10:47:28 hostname super[5099]: Status: Mac computer with Apple silicon running: macOS Sequoia 15.0.1-24A348\
Wed Nov 13 10:47:28 hostname super[5099]: Status: Last macOS startup was: 2024-11-13:10:15:48\
Wed Nov 13 10:47:28 hostname super[5099]: Status: Current active GUI user is: username (502)\
Wed Nov 13 10:47:30 hostname super[5099]: Status: Managed by Jamf Pro 11.10.2 hosted at: https://company.jamfcloud.com/\
Wed Nov 13 10:47:30 hostname super[5099]: Parameter Warning: The --display-notifications-centered type of DIALOG is ignored because dialogs are not notifcations.\
Wed Nov 13 10:47:31 hostname super[5099]: Status: macOS update/upgrade workflows automatically authenticated via saved password for current user: username\
Wed Nov 13 10:47:31 hostname super[5099]: **** S.U.P.E.R.M.A.N. 5.0.0 - CHECK FOR SOFTWARE UPDATES/UPGRADES ****\
Wed Nov 13 10:47:31 hostname super[5099]: Status: Deferral restrictions have changed since last super workflow run, full software status check required.\
Wed Nov 13 10:47:31 hostname super[5099]: Status: Restrictions configuration profile is deferring macOS major upgrades for 90 days.\
Wed Nov 13 10:47:31 hostname super[5099]: Status: Restrictions configuration profile is deferring macOS minor updates for 14 days.\
Wed Nov 13 10:47:32 hostname super[5099]: mdmclient: Waiting for available updates listing...\
Wed Nov 13 10:47:36 hostname super[5099]: Status: Some updates are deferred due to a restrictions deferral configuration profile.\
Wed Nov 13 10:47:36 hostname super[5099]: Warning: Some updates are inaccurately reporting as deferred even though restrictions deferral configuration is not enabled. As such, these updates will still be considered for installation.\
Wed Nov 13 10:47:36 hostname super[5099]: Restrictions Deferral: macOS minor update 1 of 1 is: DeferredUntil:2024-11-18 00:00:00,Title:macOS Sequoia 15.1,Build:24B83,Version:15.1\
Wed Nov 13 10:47:36 hostname super[5099]: Status: No currently available macOS software updates due to software update deferral restrictions configuration profile.\
Wed Nov 13 10:47:36 hostname super[5099]: Status: Resetting any workflow dates.\
Wed Nov 13 10:47:36 hostname super[5099]: Status: Resetting any deadline counters.\
Wed Nov 13 10:47:36 hostname super[5099]: Status: Full super workflow complete! The super workflow is scheduled to automatically relaunch in 360 minutes.\
Wed Nov 13 10:47:36 hostname super[5099]: Exit: super is scheduled to automatically relaunch at: 2024-11-13:16:47:00\
Wed Nov 13 10:47:36 hostname super[5099]: **** S.U.P.E.R.M.A.N. 5.0.0 - EXIT CLEAN ****\

The workflow does not start as expected.
Although the update appears in Software Update as 15.1 was released more than 14 days ago (16 according to Sofa) and the deferral expired, the workflow fails to initiate.

What am I missing?
Where does the DeferredUntil:2024-11-18 00:00:00 I see in the logs come from?

@I-Wildcard
Copy link

You can always set the timer for the dialog to an extended period, a several hours perhaps, so in that scenario if they started a zoom call they wouldn’t need to restart right away. Or just have set the focus deferral count so it doesn’t bother them at all during the zoom call.

This is something that I also wanted to set up but wasn't able to, as it seems that if the deadline has already passed, the timer for the dialog (DialogTimeoutSoftDeadline) is capped to 120 seconds before automatically restarting the device to complete the update.
If there was a way to set it to something like 2 hours, I'd go for the option you suggested.

@majorsl
Copy link
Author

majorsl commented Nov 14, 2024 via email

@I-Wildcard
Copy link

I-Wildcard commented Nov 14, 2024

super is simply reacting to the output of the mdmclient command.

Ok, so I did a bit of digging here, and I can see that the output of the mdmclient command for 15.1 (with a 14-day deferral) is:

 {
        AllowsInstallLater = 1;
        AppIdentifiersToClose =         (
        );
        Build = 24B83;
        DeferredUntil = "2024-11-18 00:00:00 +0000";
        DownloadSize = 2925530947;
        HumanReadableName = "macOS Sequoia 15.1";
        HumanReadableNameLocale = "en-US";
        IsConfigDataUpdate = 0;
        IsCritical = 0;
        IsFirmwareUpdate = 0;
        IsSecurityResponse = 0;
        ProductKey = "MSU_UPDATE_24B83_patch_15.1_minor";
        RequiresBootstrapToken = 1;
        RestartRequired = 1;
        SupplementalBuildVersion = 24B83;
        Version = "15.1";
    },

DeferredUntil = "2024-11-18 00:00:00 is the reason why Super's workflow isn't starting.

I am very confused though, because as far as I know macOS Sequoia 15.1 was released on October 28th, and the 14-days deferral should have expired on the 2024-11-11 00:00:00, not on the 2024-11-18 00:00:00.
To confirm this, I am actually already able to see the update as available in Software Update.

mdmclient doesn't seem to be reliable in this case - at least I understand where the issue comes from, but I'm not sure why it's setting a different date.

@majorsl
Copy link
Author

majorsl commented Nov 22, 2024

I still have no idea what is happening here. Originally, 15.1 was deferred until 12/09/24 for us. Then 15.1.1 was released and now the major OS update got pushed back for 12/24/24. Obviously, if Apple keeps releasing minor updates before the major deferral time us up, in theory you'd never get to the point where the major update is allowed.

I'm going to decrease the deferral time in our MDM and hope that it gets honored.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

5 participants