nudge
nudge copied to clipboard
macadmins
Refresh Cycles not being honored
Running Nudge 1.1.14.81546 and for the last several weeks have had to remove Nudge from production due to users reporting aggressive mode behaviors (no deferral option, screen blurring, aggressive window re-appearances) before the elapsed deadline. I am using UTC timing for the elapsed deadline, and even during testing, have pushed the deadline to a week in the future to make sure this was not a time zone issue. I've since been testing by going completely barebones with the config profile in jamf, and slowly adding necessary options. Thus far, the only consistent config has been one without any refresh cycles. Just a deadline and a target OS and target OS group. I've since added initial refresh rate of 20 min, which is not being honored (refresh rate is stuck at 10 minutes). I can not for the life of me figure out what has gone wrong, besides the fact that I recently deployed automatic Nudge updates via Jamf Mac Apps catalog. Nudge was working flawlessly until then. I tried rolling back to the last working version, restart my test machine, and even went as far as resetting the OS to test. Nothing is working to remedy the fact that the refresh rates are not being honored. Heres my current config:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>osVersionRequirements</key>
<array>
<dict>
<key>requiredInstallationDate</key>
<string>2024-04-20T21:00:00Z</string>
<key>requiredMinimumOSVersion</key>
<string>14.99</string>
<key>targetedOSVersionsRule</key>
<string>14</string>
</dict>
</array>
<key>userExperience</key>
<dict>
<key>approachingWindowTime</key>
<integer>1</integer>
<key>initialRefreshCycle</key>
<integer>1200</integer>
<key>approachingRefreshCycle</key>
<integer>300</integer>
</dict>
</dict>
</plist>
The behavior I'm looking for is 20 minute refresh cycles until 1 hour before deadline which will configure 5 min refresh cycles. I did not even get to test aggressive mode behaviors yet. The behavior I'm getting is 10 min refresh cycles no matter with refresh interval im in. Am I missing something here? I had a full fledged config before, and I feel like everything I knew (or thought I knew) about Nudge is out the window. Please help. Thanks.
@ksoliman , you appear to be missing... a lot of things in the configuration. As a habit, I define my windows and cycles for each time period so there is no doubt, and no reliance on the documentation or default settings.
You have an approaching window of 1 hour. I think you are actually describing the imminent window. Approaching comes before imminent. The behavior you are seeing may be Nudge defaults.
Initial > approaching > imminent > elapsed
@bradtchapman, Im not describing the imminent window. Older configs had imminent windows that were not being honored. Im just slowly testing with as few options configured as possible but nothing seems to be moving nudge away from Nudge defaults. Im going to re-test with an imminent window, but I'm not optimistic. Refresh cycles havent been honored regardless of which refresh phase Nudge is in. I'll report back shortly with a test with imminent refresh cycle and interval configured.
Please see the new config below:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>osVersionRequirements</key>
<array>
<dict>
<key>requiredInstallationDate</key>
<string>2024-04-16T14:00:00Z</string>
<key>requiredMinimumOSVersion</key>
<string>14.99</string>
<key>targetedOSVersionsRule</key>
<string>14</string>
</dict>
</array>
<key>userExperience</key>
<dict>
<key>approachingRefreshCycle</key>
<integer>900</integer>
<key>approachingWindowTime</key>
<integer>2</integer>
<key>elapsedRefreshCycle</key>
<integer>60</integer>
<key>imminentRefreshCycle</key>
<integer>300</integer>
<key>imminentWindowTime</key>
<integer>1</integer>
<key>initialRefreshCycle</key>
<integer>1200</integer>
</dict>
</dict>
</plist>
Ok so strangely enough @bradtchapman the cycles now seem to be working when I added an imminent refresh cycle as you suggested (It was not before), however, I am now getting elapsed refresh cycles 1 hour before the actual deadline. So my nudge prompt is appearing every 60 seconds right now even though the deadline is set for an hour from now.
Also, does this mean, that if refresh cycles are desired, you must use all refresh cycles? So i couldnt just establish an initial cycle without approaching and imminent? or an approaching without imminent and initial?
windowTimes are expressed in hours. refreshCycles are expressed in seconds.
Your approaching time is only 2 hours. Your imminent time is only 1 hour. Are you sure that's what you want ?
@bradtchapman understood. The configuration above is just a test config so short answer to your question is no, those refresh intervals are not what i want. But my question is why is elapsedRefreshCycle (set to 60 seconds) triggered before the requiredinstallationdate? I notice when "Hours remaining to update" is 0 (less than one hour remaining until the deadline), the elapsedRefreshCycle kicks in, triggering Nudge prompts every 60 seconds.
Like I previously stated, the configs posted here are what I have set up on my test machine. But to give you a better idea of the end goal, In production, we will want to initiate nudge prompts every 2 hours (7200 seconds) before the requiredinstallationdate (unless deferred, which we are just using the default launchagent for). Once the requiredinstallationdate has been reached, to initiate aggressive mode Nudge prompts every 30 seconds.
The timers are only for when nudge is running. Users can either close nudge or go to their tasks. The launch agent is what loads nudge when it's fully closed.
Your configs are way too aggressive IMO.
The configs you see on this thread are for testing purposes only and done intentionally like this so I can run several tests in one day.
@erikng I am fully aware that the refresh timers are only for when Nudge is running and what the purpose of the launch agent is. I may not be describing my issue well enough, let me try to re-word it...
My issue is that the configured elapsed refresh rate is kicking in before the required installation date, specifically when there is 59 minutes or less until the aforementioned required installation date. When I send the Nudge prompt to the background (Not deferring) when there are 59 minutes or less remaining until the required installation date, Nudge re-prompts me at the elapsed refresh rate frequency.
Unless @erikng you are stating that my test configs you see here are too aggressive, and thus the reason the elapsed refresh rate is kicking in too early, I'm not sure it has something to do with this issue.
@ksoliman : the refresh cycle times are only valid while the Nudge window is still on screen. If users ignore the window and keep working, move it out of the way, pile other windows on top etc... then Nudge will jump back to the top after the "refreshCycle" within the given "windowTime."
If the requiredInstallationDate has not been reached, Nudge will allow the user to defer by clicking some buttons. This will make the window go away and close Nudge.
When Nudge is closed, it will not launch again until the start of the LaunchAgent, which defaults to running at :00 and :30 on the hour.
As @erikng said, your window times and refresh cycles are way too aggressive.
You should be giving your users at least a few days to respond to Nudge prompts and update their Macs.
As it stands, if you deployed this configuration today, you would get a lot of complaints, and your boss would tell you to turn it off ASAP, and you might never get a second chance to use it.
@bradtchapman @erikng lol guys I promise I understand what you are saying but I think you both are missing the point. Just to satisfy your concerns about my test intervals, I've just now tested the config with the much lengthier refresh intervals below:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>optionalFeatures</key>
<dict>
<key>aggressiveUserExperience</key>
<false/>
<key>aggressiveUserFullScreenExperience</key>
<false/>
</dict>
<key>osVersionRequirements</key>
<array>
<dict>
<key>requiredInstallationDate</key>
<string>2024-04-16T22:00:00Z</string>
<key>requiredMinimumOSVersion</key>
<string>14.99</string>
<key>targetedOSVersionsRule</key>
<string>14</string>
</dict>
</array>
<key>userExperience</key>
<dict>
<key>approachingRefreshCycle</key>
<integer>6000</integer>
<key>approachingWindowTime</key>
<integer>72</integer>
<key>elapsedRefreshCycle</key>
<integer>300</integer>
<key>imminentRefreshCycle</key>
<integer>600</integer>
<key>imminentWindowTime</key>
<integer>24</integer>
<key>initialRefreshCycle</key>
<integer>18000</integer>
</dict>
</dict>
</plist>
The expectation here is that Nudge will -- as @bradtchapman says -- jump back to the front of all windows every 300 seconds AFTER 2024-04-16 22:00:00, which as of writing this is still 15 minutes from now. That means its still in the imminent phase which makes Nudge jump to the front every 600 seconds when Nudge is just worked around and not deferred.
Thats the expectation...
The reality is, with this config, still 15 minutes before 2024-04-16 22:00:00, Nudge is jumping to the front of all windows every 300 seconds... BEFORE the requiredinstalldate has expired. The imminent phase in this example has only lasted until 2024-04-16 21:00:00. Once I've reached 2024-04-16 21:00:01, Nudge is honoring the elapsed refresh rate... thats 59 minutes and 59 seconds BEFORE it is supposed to honor it.
Unless you had a typo at the end, isn't that the right time? You put 22:00:00 on the config and said at 22:00:01 it started doing it, but then say that's 59 minutes too early.
Unless you had a typo at the end, isn't that the right time? You put 22:00:00 on the config and said at 22:00:01 it started doing it, but then say that's 59 minutes too early.
Sorry yes that was a typo. Fixed in the original comment. I meant 21:00:01
I'm on sabbatical until may 8th so I won't be able to test any of this stuff for some time, but hopefully someone else can attempt to recreate and see if they can or cannot.
I think what you're ultimately saying is nudge is an hour ahead. I feel like I'd have a lot more people, including within Uber notice this so I'm still a bit skeptical.
@erikng Yes thats exactly what Im saying. You worded it much more concisely than me.
Im using a standard Gregorian calendar, UTC-4/Eastern Daylight Time, NYC
My belief is that Nudge is honoring the elapsed refresh rate when the "Hours Remaining to Update" registers as 0, which seems to be as soon as we hit 21:00:01 in the above case. I also am thinking there may be a setting I'm missing because I too don't see anyone else with the same observation, but it's not obvious to me what that setting is.
Edit: I should also add that I'm running this on a 2020 M1 MacBook Air running MacOS 14.1.2
According to the Nudge code, if you do not specify any window times or refresh cycles, Nudge reverts to the following defaults:
initialRefreshCycle: 18000 seconds = 5 hours
(remember: the implicit "initialWindowTime" begins at January 1, 1970 and ends at requiredInstallationDate - approachingWindowTime)
approachingWindowTime: 72 hours = 3 days approachingRefreshCycle: 6000 seconds = 1 hour, 40 minutes
imminentWindowTime: 24 hours = 1 day imminentRefreshCycle: 600 seconds = 10 minutes
elapsedRefreshCycle: 300 seconds = 5 minutes
@bradtchapman, Im unsure the purpose of posting Nudge default window times and cycles as @erikng hit the nail on the head with his assessment of the issue already. Nudge is operating an hour ahead with the configuration I posted last. At least it is for the elapsed refresh cycle. I'm going to test if this is true for the imminent and approaching window times, which I believe will also be triggered an hour before they should.
Edit: If you take that exact configuration I posted most recently, I think you'll also see that the elapsed refresh rate of 300 seconds is actually starting 1 hour BEFORE the required installation date
@bradtchapman See the following config:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>optionalFeatures</key>
<dict>
<key>aggressiveUserExperience</key>
<false/>
<key>aggressiveUserFullScreenExperience</key>
<false/>
</dict>
<key>osVersionRequirements</key>
<array>
<dict>
<key>requiredInstallationDate</key>
<string>2024-04-18T12:00:00Z</string>
<key>requiredMinimumOSVersion</key>
<string>14.99</string>
<key>targetedOSVersionsRule</key>
<string>14</string>
</dict>
</array>
<key>userExperience</key>
<dict>
<key>approachingRefreshCycle</key>
<integer>6000</integer>
<key>approachingWindowTime</key>
<integer>72</integer>
<key>elapsedRefreshCycle</key>
<integer>300</integer>
<key>imminentRefreshCycle</key>
<integer>600</integer>
<key>imminentWindowTime</key>
<integer>24</integer>
<key>initialRefreshCycle</key>
<integer>18000</integer>
</dict>
</dict>
</plist>
As of writing this comment, I have 30 minutes remaining until I reach the imminent Window Time. Im still currently in the Approaching Window Time which should -- as you stated -- trigger Nudge to jump to the front of my screen every 1 hour and 40 minutes. I've taken a log of everything that occurred
RequiredInstallationDate = 2024-04-18 12:00:00 UTC
- Changed requiredinstallationdate at 2024-04-17 11:02:00 UTC (24hr 58min remaining until RequiredInstallationDate)
- Restarted device 2024-04-17 11:03:00 UTC (24hr 57min remaining until RequiredInstallationDate)
- Booted back up at 2024-04-17 11:04:00 UTC (24hr 56min remaining until RequiredInstallationDate)
- Nudge prompt 2024-04-17 11:04:00 UTC (24hr 56min remaining until RequiredInstallationDate)
- Opened Firefox on top of Nudge 2024-04-17 11:04:00 UTC (24hr 56min remaining until RequiredInstallationDate)
- Nudge jumps back to front 2024-04-17 11:14:00 UTC (24hr 46min remaining until RequiredInstallationDate)
- Put Firefox back on top of Nudge 2024-04-17 11:14:00 UTC (24hr 46min remaining until RequiredInstallationDate)
- Nudge jumps back to front at 2024-04-17 11:24:00 UTC (24hr 36min remaining until RequiredInstallationDate)
Nudge, according to the documentation should not be prompting me every 10 minutes because I'm not yet in the imminent phase. Nudge appears to only be looking at how many hours are remaining until the required installation date and disregarding how many minutes are remaining as well. Its safe to say this is also happening with the Approaching Window Time as well
I found the code at fault here and you are right.
private func determineTimerCycle(basedOn hoursRemaining: Int) -> Int {
switch hoursRemaining {
case ...0:
return UserExperienceVariables.elapsedRefreshCycle
case ...UserExperienceVariables.imminentWindowTime:
return UserExperienceVariables.imminentRefreshCycle
case ...UserExperienceVariables.approachingWindowTime:
return UserExperienceVariables.approachingRefreshCycle
default:
return UserExperienceVariables.initialRefreshCycle
}
}
This will be fixed with the release of Nudge 2.0 and the upcoming pre-release build.
https://github.com/macadmins/nudge/commit/5091266d83781d3fa2195f33ee29b2209d0dca74