want a policy on JAMF that all Mac users' laptops will auto-restart after 25 days

[iqbal_jamf]

Hello There,

I want a policy on JAMF that all Mac users' laptops will auto-restart after 25 days.If anybody has it please do post.

Thanks

[mm2270]

You sure you want to do that? Without first giving users ample warning that they need to reboot their Mac on their own? That seems like a dangerous path to head down to me. It's not that it can't be done from a technical standpoint. Heck, I could send a Remote Wipe command to my entire fleet of Macs, but if I did that, I'd be looking at the unemployment line later that day.

All I'm saying is, be careful with this, because an unannounced reboot in the middle of a work day could cause important work to be lost for some employees and you could land in some hot water over that. Of course, if these are school devices used by students or even lab machines, then there's less of a risk, so you can probably ignore what I just said.

With that out of the way, yes, there are ways to do this. If you would like to have users prompted first, I would suggest considering a gradually intensive approach. Maybe at 20 days, start popping up messages on their screens that they need to reboot their Mac. Make the pop up happen each day and then on day 24, maybe have the pop up message come up on every check-in to really annoy them into doing it on their own. If by day 25 of uptime they haven't restarted, then you might be justified in force restarting, since they've had ample warning and opportunities to do so before it got to that point.

This can be done in a few different ways. For example, you could deploy a LaunchDaemon and script that ran on a set interval (every 20 minutes for example) and checked the uptime to see if we've gotten to 25 days or 20, etc and then take the necessary action.

You could also capture uptime in an Extension Attribute in Jamf Pro, build a Smart Computer Group from that criteria to gather devices showing X number of days uptime, and then have a policy using that Smart Group as the scope run on next check in to do what you want.

And there are probably other ways to do this I'm not currently thinking about. Notice I'm not going into details on how to set this up. This is just an overview, high level, of how you can go about it.

To start you off, you can look at getting an Extension Attribute in place that gives you the uptime of devices. Keep in mind that information will only ever be as good as the last inventory, so use some caution. A device can reboot, but until it next submits inventory to Jamf, might still show as having a high uptime value.

There are several existing good examples of how to capture uptime here on the forum. Here's the one I use, which uses a different approach. I capture last reboot time in a Jamf Pro friendly time format. I can then use that criteria in a Smart Group to see machines that are over a set number of days since last boot up. I can put in for example Last Boot Time | more than x days ago | 20

#!/bin/sh

last_boot_time_unix=$(sysctl kern.boottime | awk -F'[= |,]' '{print $6}')

last_boot_time=$(date -jf "%s" "$last_boot_time_unix" +"%Y-%m-%d %T")

echo "<result>$last_boot_time</result>"

 You could build a few Smart Computer Groups. One for for more than 19 days and less than 25 days (captures 20 - 24 days uptime) and then a group for more than 24 days, which would capture all Macs with 25 or more days of uptime. Then create policies that will run against machines in those groups to send up messages, or in the case of the 25+ days, reboot on next check. 

Example:

/usr/local/bin/jamf reboot -immediately

or

/usr/local/bin/jamf reboot -minutes 1

[sdagley]

@iqbal_jamf +1 to all of the caveats that @mm2270 raises on forcing a restart. His post also provides you a good framework for implementing a system to do what you want but if you're looking to leverage something that's already been written take a look at https://github.com/SecondSonConsulting/Renew to see if you can adopt it (be sure to check the Wiki associated with it).

[user-dIrrpGXxza · Accepted solution]

We have this implemented, but after a longer period which is 60 days because of the concerns posted by others in this thread.

Here's how to do it:

Step 1 - implement an extension attribute using the following script/config:

Data type: YYYY-MM-DD hh:mm:ss

Inventory display: Operating system

Input type: Script

The script:

#!/bin/bash

# Get boottime in epoch time, convert to Jamf Pro formatted time and make an extension attribute
#
# Updated: 2.23.2022 @ Robjschroeder
#

bootTime=$(sysctl kern.boottime | awk '{print $5}' | tr -d ,)
formattedTime=$(date -jf %s $bootTime "+%F %T")
echo "<result>${formattedTime}</result>"

exit 0

Step 2 - create smart group:

Criteria: <your extension attribute> - More than x days - input 25, 60 or whatever days here

Step 3 - create policy and scope it to the above smart group:

* Configure the general tab with recurring check-in as trigger, and make it recurring once a week so that it doesn't trigger again until an inventory update has been run in the vast majority of cases

* Configure restart options in the policy as desired

* Configure the User Interaction tab, preferably with a message with what is about to happen, preferably with a deferral type for x days (we use 3)

And presto!

[gabester]

Compare and contrast sending down a script or Files and Processes command line payload with the Restart Options payload... I've got a set of smart groups leveraging an "uptime" extension attribute which are the scoping criteria for a set of policies which first warn a user with increasing frequency as recommended by @mm2270 and then finally execute the Restart Options payload policy. I also restrict that policy to off hours... so if you hit day 31 and you left your Mac on after 2AM, that restart chime might wake you up; if you wake it from sleep at 6:30am you'll get a 5 minute timer as part of the Restart Options payload.