Awesome feature update! Thanks Automox team for this one, I am eager to try it out! Can we get a little explanation on how this works with the button trigger “If a device misses a configured patch time, it will patch the next time the device checks in.”

Cheers!

If a device misses a patch time, they’ll still see a notification (if notifications are enabled) the next time the device checks in.

Notification timeouts and deferrals should work normally from that point on.

For updated documentation related to User Notifications, see our Help Center docs:

https://support.automox.com/help/end-user-notifications


https://support.automox.com/help/using-reboot-notifications

With this enhancement has the spontaneous reboots also been resolved if a user shutdown or reboot the machine within the deferal period?

These features greatly reduce the chance of any surprise reboot, especially if automatic deferrals are enabled.

For a long-term fix to what you’re describing, we’re looking at better detection for user-initiated shutdowns/reboots. That’s not in this release, but it’s something we’re planning.

just out of curiosity why is this long term fix because in our heads it’s sounds as an easy to fix issue?

It’s your typical combo of “things are a bit more complicated under the hood” (e.g. tech debt and historical reasons why we originally set things up one way that can make simple fixes harder down the line) and “there’s high priority new feature work to compete with” (e.g. multi-group membership and dynamic groups).

Interesting as this would be our chief complaint - nobody likes to hear the Ceo’s laptop shutdown during an important meeting.


Its too bad the user can’t choose to pull the updates or be given some kind of time frame to keep their computer online, or that the update happened and is complete.

Just my 2 cents.

Curious on how other customers are handeling reboots. Patching and rebooting it’s never convenient but sudden spontaneous reboots will reduce adoption rates and project progress, user satisfaction and will result in possible data loss.

I would also categorize this as a defect instead of an enhancement.

I am also curious. I believe I read previously that there was a suggestion to leave the computers on overnight but that doesn’t really work for us.

Agree completely, and it is something we are working on fixing. There’s a couple of different reasons why you sometimes get those surprise reboots, and a manual reboot not clearing that flag on the Automox side of things is one of the root causes that we’re working on solutions for. If you can train your users to wait for the Automox reboot that’s the best workaround in the meantime. Or if they do a reboot on their own, they should understand that Automox might also prompt them to reboot. With the new deferral features we’re expecting that most of the “surprise” reboots will go away, as a lot of those are from people being away from their computer during the (previously fixed) 15 minute notification window. With the ability to customize that window and also consume a deferral automatically, that should handle 95% of the use cases.

I’ve been using a home-brew worklet that schedules multiple tasks running in user context to accomplish notifications of an enforced reboot (hourly for five hours and every 15 minutes in last hour). Two more scheduled tasks exist to cleanup if a user initiated reboot occurs. Reboot being detected using a scheduled task triggered by the TASK_TRIGGER_BOOT method described here https://docs.microsoft.com/en-us/windows/win32/taskschd/triggercollection-create

Example worklet for notifications. Windows - Notify User with Balloon Tip Pop-up

I’m now running this process on about 900 endpoints that took compliance from about 80% to 90% higher patched as measured by vulnerability tools. My 10% missing is mostly out of software not being patched by Automox or computers that go offline. Reboots are no longer my constraint.

The gotcha I did not anticipate was picking up on behavior of failed patching and users being asked to reboot daily. Still working on API calls to monitor for that type of feedback loop.

I’m eager for Automox to get to this fix, but would agree that the other areas prioritized propel us far faster than the reboot one. Only because I have some shoe-string and duct tape of a worklet I built helping us along 🙂

Here is the exact worklet I’ve been using – Worklet - Enforced Reboots with Notifications using Scheduled Tasks

Really helpful insights Jack, we have similar experience also using ductape to work around the reboots 😬

I’m finding this isn’t working for me as expected, I’ve been doing some testing and set the deferrals to 10 and changed the times to allow 24 hours as one of the options, however, my machine notified me 5 times and then rebooted the machine without warning.

I’m testing this before I roll it out to the users as we had issues with it before, auto rebooting users without warning.

Is everyone else getting this issue?

Kind Regards,

Mike

@Mike_Hawkins


I’m experiencing a varied amount of issues with the notifications (constant popup, not appearing at all, reboot no button not working). Have spoken with Automox support who have said a lot of this will be resolved in the next agent release… in Q3.


Your issue might fall into this also?

This is affecting several of our clients too.