Released Today - Custom Reboot Timeout and Automatic Reboot Deferrals

Today we released two new patch policy features to give admins even more control over end user notifications:

Customizable Reboot Notification Length
Admins can now customize the length of time that a reboot notification is displayed to the user, from 15 minutes up to 8 hours.

Automatic Reboot Deferrals
Admins can now enable automatic reboot deferrals when end users do not acknowledge the reboot notification at all.

One of the user’s available deferrals will be automatically consumed on behalf of the user until they are out of deferrals. Automox will choose the longest available deferral time.

Once a user is completely out of deferrals, their machine will restart instead.

3 Likes

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.

1 Like

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

3 Likes

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.

2 Likes

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.

2 Likes

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.

1 Like

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.

2 Likes

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 :slight_smile:

1 Like

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

1 Like

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