Support

Usage guide: Device restart enforcement

This page outlines various ways to use the pack, including use case examples.

Administrators can refer to the Configuration guide: Device restart enforcement to set up and customize the installed content.

Restarting devices regularly is critical to maintaining performance and applying system updates. This library pack supports IT teams in encouraging compliant restart behavior while balancing user experience.

The Device restart enforcement library pack enables IT teams to:

  • Identify devices that haven’t been restarted for a specific duration.

  • Offer users multiple opportunities to restart voluntarily.

  • Automatically trigger restarts on non-compliant devices using targeted campaigns and remote actions.

  • Reduce patch deployment failures due to pending restarts.

Library pack uses

Jump to Use cases on this page to see relevant scenario applications.

Use the library pack content for the following purposes.

Visibility

This library pack focuses on the 'Device restart enforcement' workflow. This workflow is designed to help automate the sending of password expiration reminders to employees through multi-level checks and reminders via campaigns and emails. With support for both on-premises Active Directory domains and Entra ID environments, the workflow provides a universal way to help reduce the disruption caused by expiring passwords and the IT support workload associated with this issue.

Workflow triggering

The workflow has been designed primarily to be run manually. For example, you can run an investigation that queries for non-server devices that have not been restarted for more than one week by using the NQL query below:

NQL:

Code
devices during past 7d
| where operating_system.name !in ["*server*"]
| where boot.days_since_last_full_boot > 10

Alternatively, you could also set a schedule for the workflow to be automatically triggered, as shown below:

NQL:

devices during past 7d
| where operating_system.name !in ["*server*"]
| where boot.days_since_last_full_boot > 10

Predefined workflow structure and steps

The device restart enforcement workflow is structured into the following main steps:

  1. The central point of the workflow is the Nexthink Repeat function, which repeats the steps inside it a defined number of times (three times by default) if the desired condition is not met in the cycle, and after a defined timeout. In this case, the desired condition is user confirmation to restart the device now.

  2. Inside the Repeat block, the logic is as follows:

    1. First, the workflow checks how many days have passed since the device was last restarted. If the device was restarted within the last 10 days, the workflow will terminate. If it was restarted more than 10 days ago, the workflow will send a campaign to the user. This campaign will inform the user of the need for a restart and offer three options: Restart Now, Postpone for 1 Hour, or Postpone for 1 Day.

    2. If the user selects to restart the device now, the workflow will trigger a remote action corresponding to the target device platform (macOS or Windows).

    3. If the user selects to postpone for one hour, the workflow will repeat the campaign after one hour.

    4. If the user selects to postpone for one day, the workflow will repeat the campaign after one day.

    5. If the campaign expires on a target device, the workflow will trigger it again in three minutes.

    6. If the user selects Postpone three times, the workflow will terminate without restarting the device.

Last updated

Was this helpful?