Update windows?

[Gregory Neagle]

I’ve been asked by our CTO to look into providing a way for users to set their preferred windows for update notifications.

I’m a bit undecided in how I might approach this.

I _think_ the desire is to be able to prevent MSC from notifying about updates during important/sensitive times. So the proposal was to be able to tell Munki: “please only notify me in the mornings before 10am, or please only notify me in the afternoons after 4pm”, or “please notify me only around lunchtime”.

The other thought I heard a few times was that the “random” timing of the notifications was stressful, and that being able to choose a window of time would combat that.

I will continue to have conversations with management to better understand the desire/request here. But has anyone here thought about something like this? Some questions and concerns I have:

- In order to notify inside a specific time window (especially if that window is small) there may need to be Yet Another Process that either runs continuously (or at least far more frequently) than managedsoftwareupdate does currently. Otherwise, the ~hourly run of managedsoftwareupdate could miss that window.

- How would users discover this feature? Should there be new UI in the Updates view to set this window (or at least a link/button to the UI to do so)?

- Since not every org would even want this I’ll have to implement a preference to turn it on (and therefore leave no hint of its existence when not enabled).

I would be interested to hear other’s thoughts and reactions to this. Have you had similar conversations with your users? With your management?

-Greg

[Ben Toms]

I’ve had the conversation a few times with folks in EDU where they wanted updated to be applied outside of the teaching day.

So, like from 5PM.

But, this is the simplest implementation. As the UI would be the same as whatever Munki would show.. and, there wouldn’t actually be a user on the Macs at that time.

To set this, we’d use something like Jamf Pro’s binary to enable/disable the launch daemons on a schedule.

I’m sure this is the most simplest version.

Regards,

Ben

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/munki-dev/F1527405-CBDD-466D-8950-D21DEDDF36F3%40mac.com.

[Jim Zajkowski]

The way we do this is we just eject out of the preflight if our scheduling backend decides now is not a good time:

  # auto runs: should we stop?

  if [[ "$1" == "auto" ]]; then

    # if the scheduler returns zero, that means run now; anything non-zero we want to stop running.

    if ! /usr/local/izzy/bin/izzy scheduler; then

      exit 1

    fi

The scheduler is entirely server-side, to accommodate a bunch of different situations.

By only stopping on “auto” runs we let tech teams and users run MSC without apparent interference.

—Jim

[Nate Walck]

Initial thoughts, I see two major workflows here:

1. User selected update window, with UI/UX for setting this window
2. Configured Windows with zero user UX (the case like Ben mentioned) 

There would also need to be a way to override this window (both flavors) if there is a critical update you need installed ASAP. 

As for the user selected window, one can imagine a week view, where you can select days and window hours using something similar to a calendar interface, but just the click and drag mechanism for making the window larger/smaller. 

Nate

[Jim Zajkowski]

As to this: we used to drop a System Preferences pane that let people configure their schedule (if the server allowed it for that client). We ended up pulling it because used it and/or they’d just send in an email.

—Jim

[gregn...@mac.com]

Configured/controlled by admin is "easy" and requires no code changes to Munki, and can be implemented in a Munki preflight script or something external that configures/controls the "SuppressUserNotification" preference.

User-controlled is the challenge. And implementing this in a way that is useful for the largest number of orgs is a challenge. For example, I think I'd want to disallow people saying "notify me only from 12am-4am" (as an example) because that would just be a sneaky way of saying "never notify at all". But other orgs might want to allow that for _reasons_...

[Nate Walck]

Agreed. It might make sense to allow the admin to configure “core hours” where the user can select when they want the updated. Anything outside of core hours would be non-selectable by the user (and would be “normal” operation of munki outside of core hours). Using Local time would make it easier, no need to worry about time zones then. 

The default would be any time in core hours, with the user being able to select a specific time frame during core hours they want (which would then cause munki to skip auto runs during the unselected core hours). 

Nate

--

Find related discussion groups here:

https://github.com/munki/munki/wiki/Discussion-Group

---

You received this message because you are subscribed to the Google Groups "munki-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/munki-dev/f7d5b54a-f6c5-4f10-9c77-ce8a22b73ac4n%40googlegroups.com.

[Elliot Jordan]

I like this idea, and hour-of-day and day-of-week support seems like a reasonable initial scope. It could get quite a bit more complex if you try to support day-of-month (e.g. patch Tuesday) or week-of-year (e.g. late December change freeze) logic.

I might suggest that the user-configurable schedule might be for opt-out periods rather than opt-in periods. That communicates a policy of "update always unless told otherwise" while still retaining user choice.

An MDM-deliverable schedule layer that overrides/limits user choice, both for specific hours (e.g. enforcing a Friday 9-11pm maintenance window that cannot be overridden) and for specific updates (e.g. a particularly critical update [pkginfo] that can bypass user update schedule), would be ideal. Otherwise I predict some users might try to disable updates entirely if given that option.

+1 to configuring all of the above in local time for simplicity.

Thanks Jim for sharing that preflight script — simple and clever.

Elliot

To view this discussion visit https://groups.google.com/d/msgid/munki-dev/f3f8e5f1-d05a-4b62-aae9-28aec6569476%40app.fastmail.com.

[gregn...@mac.com]

Some nice ideas so far, but I'll caution everyone that if it's _me_ doing the implementation, I'll focus at least initially on what I've been requested, with it being admin opt-in. 

IOW, I was asked for windows of time where notifications could occur, and not windows of time where they won't. There was also no request for day-of-week.

I'm not saying those are unreasonable ideas, but if I'm doing the work, I'm going to focus on what senior management here has asked for and not attempt to build something that's infinitely flexible to cover everyone's ideas/wants.

(And I definitely will  _not_ suggest to senior management here "I know you asked for foo, but how about foo _and_ bar, _and_ baz?" Because they might say yes.)

-Greg

[precu...@gmail.com]

This is an interesting discussion.

I  have found that the time a user might accept as valid for a notification changes with each person and even for each person depending on circumstances. 

For some people lunchtime is good. 

But then I once saw a person who said lunchtime was good have a meltdown when a notification appeared during a lunch presentation he was making.

My feeling is that Apple has already solved this problem by providing the "Focus" feature which provides for "Do Not Disturb" in a variety of profiles, like "Work" 

The advantage of Focus is that if the user learns how to use it they can control notifications not only for munki but for everything that might disturb/interupt them.

[Kevin M. Cox]

This was my initial thought as well. Why not just piggyback on Focus/DND to silence notifications.

Unattended installs still run in the background as usually every hour, but anything that requires notifying the user is silenced.

Then some sort of logic to break through Focus/DND for "force_install_by_date" items that are within a certain threshold of the deadline.

~ Kevin

To view this discussion visit https://groups.google.com/d/msgid/munki-dev/cb604ab0-3cc4-42b2-abb5-1cf9c17cc05an%40googlegroups.com.

[Gregory Neagle]

What is the API to read current Focus/DND status? How do you prevent users from setting DND from 12:00am to 11:59pm?

Sent from my iPhone

On Feb 1, 2026, at 5:26 PM, 'Kevin M. Cox' via munki-dev <munk...@googlegroups.com> wrote:

This was my initial thought as well. Why not just piggyback on Focus/DND to silence notifications.

To view this discussion visit https://groups.google.com/d/msgid/munki-dev/AF798AE9-9592-48EB-AF76-417E8806BD09%40kevincox.com.