Getting Users to Reboot Their Machines w/ Automated Encouragement

“Did you try restarting your computer? …” is undoubtedly the most common question asked by IT to users.  And perhaps unsurprisingly, the majority of user issues get resolved by completing this simple task.  Before most computers had SSDs, this wasn’t a task most users wanted to do for the simple reason that it took several minutes to close all running applications, reboot, get back to the login screen, and then fully load the OS.  Thankfully, most laptops now have SSDs and so this task is significantly faster – 10 to 30 seconds total at most.  And yet we still struggle to get our users to reboot.

Rather than wait for the Helpdesk tickets and phone calls to come in, we’ve taken a more proactive approach to encourage our users to reboot their computers themselves.

There are 4 things that make this work:

  1. An extension attribute to collect the last time a machine has rebooted
  2. A smart group to collect all computers that haven’t been rebooted after the desired amount of time
  3. A script that presents the desired notification using jamfHelper
  4. A policy that presents the notification to the user

Whether or not you’re looking to have your users reboot on their own, this same structure can be applied to other notifications you may want to present to your users.  As an example, we use a similar structure to inform our teachers and administrators when their internal storage has less than 25% free space, as well as less than 10%.

See below the jump for more details.

Last Reboot Extension Attribute

There’s a great EA on Github written by Jason Bush that collects the last computer reboot in jamf’s date format (YYYY-MM-DD hh:mm:ss).  Thanks, Jason!

Screen Shot 2018-01-25 at 2.51.41 PM.png

Needs Reboot Smart Group(s)

In our environment I’ve created several different groups for notifying users to reboot:

  • One for our faculty and administrator laptops
  • One for our student cart laptops
  • One for our desktop lab computers

There are 3 purposes for these differentiated groups:

  1. To customize the message users receive
  2. To customize the timing of when users receive our message
  3. To customize the frequency our reboot policies run and present our message

We use a number of naming schemes to ensure all our related groups, scripts, and policies are listed next to each other.  We also have a dedicated “Helpdesk Alerts” category in our JSS to group these applicable notification policies.

Screen Shot 2018-01-27 at 11.28.30 AM.png

Each of our smart group’s criteria include the “Last Reboot” extension attribute and either the computer name(s) of the applicable machines or membership in another smart group that have all the desired machines.

Personally, I’ve tended to stay away from using membership in a smart group as criteria in another smart group given the potentially undesirable policies & configuration profiles that might run or be removed from computers falling out of that single smart group.

Screen Shot 2018-01-25 at 3.30.21 PM.png

We want our users to reboot their machines once every 3 weeks, but you can of course increase or decrease this number as desired.  We specify more than x days ago with a value of 20 so that computers fall into our respective smart groups on day 21.

Especially if you are just implementing something like this for the first time, you may want to know (at least initially) when users need to reboot and confirm when they have rebooted.  In these situations we enable the “Send email notifications on membership change” smart group checkbox.

Screen Shot 2018-01-27 at 11.19.16 AM.png

Notification Script(s)

Using my jamfHelper Notification template as a base, we have different messages based on whether it’s for faculty and administrators or student cart machines.  You can get more details on command line use of jamfHelper by running jamfHelper -help, but you can also find the full list on my Github here.

While not critical in this case, as the script is the only payload in our notification policy, I set the below scripts priority to run before other policy payloads.

Screen Shot 2018-01-27 at 11.33.42 AM.png

Faculty / Administration Script


JAMFHELPER="/Library/Application Support/JAMF/bin/"
title="Helpdesk Alert"
heading="Please Restart Your Computer"
icon="/Library/Application Support/JAMF/bin/"
buttonone="I understand"
message="Your computer has not been restarted in more than 3 weeks. If you recently restarted, please disregard this message.

As soon as you are able, please save your work and restart your computer.

This message will reappear once a day until a restart has been completed."

"$JAMFHELPER" -windowType "$window" -title "$title" -heading "$heading" -description "$message" -icon "$icon" -button1 "$buttonone" -defaultButton 1 -timeout 300

A few additional notes:

  • jamfHelper will respect line breaks in your notification messages, thus the separate lines for the message variable above.  This is why I don’t have a single script with our notification template and then employ parameter arguments (like $4) in the script payload attached to our policies to change the notification text.
  • The -timeout flag will automatically close the jamfHelper notification after X seconds if not interacted with.  You may not want this, but without this the policy won’t fully complete until the user interacts with the notification.
  • Within the jamfHelper app there are already a few image files available (shown below).  However you can point to any PNG image on the Mac to include as part of your notification.


Student Cart Script


JAMF_HELPER="/Library/Application Support/JAMF/bin/"
title="Helpdesk Alert"
heading="Restart Computer When Finished"
icon="/Library/Application Support/JAMF/bin/"
buttonone="I understand"
message="The computer you are using has not been restarted in more than 3 weeks.

When you are finished using the computer, please choose Restart from the Apple icon at the top left of the screen, rather than Logout.

Thank you.

- The Helpdesk"

"$JAMF_HELPER" -windowType "$window" -title "$title" -heading "$heading" -description "$message" -icon "$icon" -button1 "$buttonone" -defaultButton 1 -timeout 300

Reboot Notification Policies

A couple disclaimers about the policies below:

Disclaimer 1

Our environment has come up with a solution for our Macs to achieve machine-authentication on our network.  As a result, all our machines are already connected when a user gets to our login window and authenticates, so I can’t speak to using the “Login” policy trigger (in the case of our student cart laptops) when machines depend on individual user network credentials.

Disclaimer 2

If and when users reboot our Macs as a result of our notification message, the only way for these computers to fall out of their respective “Needs Reboot” smart groups is to complete an inventory update.  Our default inventory update policy runs after 24 hours since a computer’s last inventory update (rather than simply have the update inventory policy trigger once a day), but in the event a rebooted computer has already completed this update our notification policy may run again even after a reboot has been completed.

To avoid this scenario as much as possible, we have a second update inventory policy configured which is triggered at startup to help ensure users don’t receive a duplicate reboot notification after they’ve already rebooted.

Screen Shot 2018-01-27 at 10.30.41 AM.png

Administration & Faculty Computers

While we want all our administration and faculty to reboot, we don’t want to inundate them with reboot messages nor do we want to be disruptive to their work.  As such, we’ve made a number of choices with regards to the frequency & Client-Side Limitations in our reboot notification policies to strike a balance for when users receive and don’t receive these messages.

  1. Policy Run Frequency – Once a Day
  2. Policy Trigger – Check-in
  3. Scope – Administrator & Faculty Computers – Need Reboot smart group
  4. Client-Side Limitations – Don’t Run Between 10pm – 12pm

Screen Shot 2018-01-26 at 10.00.29 PM.png

Screen Shot 2018-01-26 at 10.01.26 PM.png

  • Having the policy run once a day makes the message a helpful reminder in the event the user does not take immediate action after seeing the first notification.
  • Having it trigger at check-in ensures they get a notification on their computer as soon as they pass the 3 week threshold and fall into our smart group.
  • We don’t want faculty to see our reboot message the first time they start up or open their laptop in the morning and potentially interrupt their class-time, nor do we want to bother them on the weekends.

For these reasons we limit the policy to the work-week and after lunch.

Student Cart Laptops

Because our laptop carts get used by different students throughout the day, it was important to ensure that we notified each student once during their session, rather than present this message only once for the laptop itself.  The likelihood of a student forgetting to reboot the computer instead of logging out is high, so this policy is configured a bit differently than for our administration and faculty.

  1. Policy Run Frequency – Ongoing
  2. Policy Trigger – Login
  3. Scope – Cart Computers – Need Reboot – Student Only smart group
  4. Client-Side Limitations – Don’t Run Between 3pm – 7am

Screen Shot 2018-01-26 at 10.00.38 PM.png

Screen Shot 2018-01-26 at 10.02.35 PM.png

  • With a policy trigger of login and a run frequency of ongoing, students are notified only at the beginning of their computer session on any given cart laptop.
  • Our configured client-side limitations ensures this doesn’t run any time after the regular school day and only on weekdays.

Lab Desktops (Automated Reboot)

Unlike our Administration / Faculty and Student Cart Laptop policies which depend on our users to actively reboot their laptops, we automate the reboot timing of our lab desktop computers to happen late in the evening once a week.  While we don’t need to display a notification in this case, it is important to ensure these reboots happen when they are not being used by students, don’t interfere with our daily JSS database backup, and don’t unintentionally impact scheduled maintenance windows.

We configure the policy to trigger once a week on recurring check-in.  This has the benefit of not unnecessarily causing a computer to reboot each time it checks-in, as our automated inventory collection policy is configured to not occur after 4:30pm (ensures computers aren’t updating during maintenance windows) and as a result would not update inventory and also not fall out of our smart group.

Screen Shot 2018-01-26 at 9.38.20 PM.png

Screen Shot 2018-01-26 at 9.38.51 PM.png

Configuring our policy to only run between 1am & 6am and only on Fridays avoids the previously mentioned issues, and helps ensure our lab desktops are pretty much on the same number of days since their last reboot.

Reboot Policy Results

Since implementing these reboot notification policies we have seen significantly fewer tickets and calls from users about issues related to not rebooting their Macs.

Additionally, having an extension attribute that collects the last computer reboot allows our Helpdesk to confirm the last time this occurred to help rule out this troubleshooting step when users communicate issues with their Mac.

Hopefully this framework helps you implement something similar in your own environment!


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s