Force Users to Restart or Shutdown by Profile not Policy

Given the core issue you've described, in that sometimes a Mac will stop checking into Jamf, then using a policy, as you already described, won't really be a good solution. You need something that will work "offline" and even when not connected to Jamf (regardless of if the device is successfully able to check in or not).

One possible way to address this would be with a LaunchDaemon and companion script. The script could run periodically, say every 5 minutes, checks the uptime, and if it's less than 5 days, then it just exits. If it's equal to or more than 5 days, it can alert the user and start a 120 minute shutdown countdown.

Do you think something like this could work for your scenario?

Yes, that would be perfect. Any chance you have a script you can share?

I was testing last night using an Energy Saver profile set to Schedule a shutdown day and time, but it appears that gives the user a 10min countdown including the ability to cancel. If the laptop is in Sleep, the prompt displays when the laptop is opened, but again gives the option to Cancel. I would love a way to force the Energy Saver scheduled Shutdown.

Hi. I don't have an exact script already created to do this, but putting one together won't take long. Give me a little bit and I will post back with a draft of something you can try.

One thing I didn't mention about the above is that, once a LaunchDaemon is deployed, you don't have direct control over how it functions. You can always adjust the script or LaunchDaemon or even disable it from a Jamf policy if needed, but when the Macs are disconnected from your Jamf server, either by not being on the proper network or some other reason, it will continue to run independently from Jamf. That's both good and bad, so just something to keep in mind.

That would be great, thank you!

The LaunchDaemon seems to accomplish what I am looking for because I want this to run regardless of connection to Jamf. These devices are company owned and managed as well as enrolled in ABM. I am not sure I see any risk of this LaunchDaemon running uncontrollably. What cons concern you?

I don't have any major concerns about it. It's just that unlike a Jamf Pro policy where you can quickly go into the policy and either disable it entirely, or add a system into the Exclusion tab to ensure it won't run on it, once you push out a LaunchDaemon and script, it won't be dependent or tied to anything in your Jamf console. You can still manipulate it from Jamf, but would need to put some commands into the Execute Command field or craft a script to make any changes to it, and then wait for your devices to check in. Not quite as direct as with policies, but not horrible either.

And no, there's really no risk of it running uncontrollably that I see, other than if something happened with the script where it stopped detecting the correct amount of uptime somehow.

Got it. We can do extensive testing on our side before deploying across 500+ machines.

If you have a Daemon and script you could share, that would be great, as I am not sure how to make one.

Thank you!

Here's an example script. Feel free to edit it however you need.

For the LaunchDaemon, it would be something like the following:

The above has generic info in it, so you have to change the "com.company.label" string to something that makes sense for you. Usually those are in reverse URL format, like com.acme.uptimereminder or something.

Also change the /path/to/script_name.sh with the actual path to where the script would be pushed locally on the Mac.

Lastly, the "300" integer value means it runs every 5 minutes (300 seconds), which is more than enough. You could shorten or lengthen that, but I'd suggest avoiding having this run too frequently since you're talking about only needing to take action after 5+ days of uptime. Even every 30 or 60 minutes is probably frequent enough actually.

Try those out and let me know if you run into any issues with it.

I've updated the script and Daemon to match my needs for testing. I first created the script in Jamf and ran it via Policy successfully. But when trying to load and run it locally I am having issues. When running launchctl list I get Status 78.

1. I created the shell script in BBEdit and saved it to my downloads.
2. Then moved it to my usr/local
3. I then created the Daemon and saved it as com.company.forcedshutdown.plist
4. Then copied it via Terminal to /Library/LaunchDaemons.
5. I then ran sudo launchctl load -w /Library/LaunchDaemons/com.company.forcedshutdown.plist
6. Then ran sudo launchctl list and saw the Status 78.

Did I miss a step?

Hey there. It's most likely the owner/group and permissions on the LaunchDaemon that aren't set correctly, but it might be helpful if you could post how the LaunchDaemon is formatted here when you can.

But in the meantime, launchd jobs have to be set to an owner/group of root/wheel, and the POSIX permissions usually need to be 644. You can fix these by running these commands in Terminal

Then try loading it again.

Edit: Just taking one other look, running launchctl error 78 indicates:

78: Function not implemented

Which isn't particularly helpful. Maybe post the LaunchDaemon plist contents when you can. There may be some formatting error or something.

Those commands don't appear to have made a change. Here is what I see before and after:

-rw-r--r--@    1     root     wheel      427     Apr  7     18:05    com.company.forcedshutdown.plist

Can you post the contents of the LaunchDaemon plist? Or if you prefer not to do that, then run this against the plist to see if it's verifying as a valid xml file

xmllint --format /Library/LaunchDaemons/com.company.forcedshutdown.plist

Ok, I believe the problem is in this line

Believe it or not, with a Launchd Program or ProgramArguments string, you don't need to escape spaces, so remove the \\ character. It should look like this:

But a quick word of advice - when naming scripts, it's really better not to use spaces. Replace them with underscores or dashes to avoid any future problems.

That worked! Thank you. Yeah I normally stay away from the spaces in file names but had seen a Jamf video where there were spaces in their script name. The \\ came from dragging the file name into terminal when finding the path I think.

Thank you again. We will do some more testing before packaging and deploying to our users via Jamf.

Hi! Testing has been going great and I am playing around with some of the JamfHelper options. One thing I cannot figure out is how to let the user acknowledge the countdown and close the window without initiating an instant shutdown. I tried adding -cancelButton as well as -showDelayOptions, but neither worked. Any ideas?

Hmm, yes, that's possible with a little reworking of the script.

Change this section of the script

Note this section of the updated script

## Changes:
## '&' is added to the end to place the dialog in the background
## changed to 'utility' from 'hud' and added OK button to the window
## changed 'shutdown -r now' to 'shutdown -r +120 to initiate a 2 hour countdown to restart

So basically, the dialog comes up, stays on screen for the duration, OR the user can dismiss it and the restart countdown continues in the background either way.

Keep in mind though that because this is a 2 hour delay, some people could forget that their Mac will restart and end up surprised when it spontaneously restarts in the middle of something later.

Thank you!

Testing is going well and we've made a few tweaks. Most notably, we had to initiate the shutdown before the Jamf Helper window, otherwise the shutdown minutes didn't seem to start until after they hit Accept. This meant they could wait 120min then the timer would shutdown in another 120min for a total of 4hrs from pop up to shutdown. Second, we've found that putting the computer to Sleep during the countdown pauses the countdown, but I am not sure that is a critical issue.

Where we still have issues/testing to do is actually around deployment through Jamf. We want to load the daemon after the package is deployed, but if a previous version is already running, you receive an error as you can't load a plist that is already loaded. You also can't unload a plist that isn't loaded, so we can't always unload before load. Any ideas?

Were you able to get this script to work? I've been playing with this copy of it and didn't go the daemon route, just running it with reoccurring. The original one caused a reboot loop, so I'm testing yours now. Any modifications you suggest or recommend since this was posted?