Jamf agent might be causing my users to reboot during sleep

dtempleton
New Contributor II

I've got this issue where about 25% of the Macs at my company (all enrolled in Jamf) are rebooting when they are left asleep for many hours (ie. overnight). They are not rebooting if they are left with the screen off but the computer awake.

Sometimes they are full reboots, sometimes they are hibernated. I'm having trouble figuring out the ratio of each as the difference is subtle for non-technical users.

I'm posting this here because I have no idea if this is Jamf's fault or not; it could be Spotify for all I know, and obviously there are a lot of things the Macs in my office have in common besides Jamf. I do know that I rolled out Jamf to everyone in March and all the complaints started rolling in in March. Technical users are putting 1-and-1-together, and think it's Jamf, and found the terminal command to remove Jamf and are running that command without my approval, which is a nightmare. But then they are telling me that the issue went away the following morning!

Many are on 10.11.6, some are on 10.12.3/4. There are various Macbook Airs, 2014-2015 MacBook Pro 15"s, and both 2016 MacBook Pro models.

I'm wondering if anyone else is having these issues. Also, I'm wondering if anyone has suggestions for looking at the logs. I go into Console.app and poke around and can't find anything relevant from the previous boot.

16 REPLIES 16

dtempleton
New Contributor II

I should note that there's obviously no settings etc that my JSS should be pushing that should be causing this. I've enrolled everyone but I'm using the JSS for minimal things at the moment: 15min screen lock, creates an additional admin user account, and pushing a network payload with the wifi profile. Everyone's computers are getting the same treatment; I haven't created any groups or scoped any settings selectively.

myronjoffe
Contributor III

Seeing the same if not similar issue. In the process of narrowing it down. Will let you know if i find the culprit...

bentoms
Honored Contributor III
Honored Contributor III

@dtempleton Are these fv2 encrypted?

myronjoffe
Contributor III

@bentoms Yes... What you thinking?

bentoms
Honored Contributor III
Honored Contributor III

@myronjoffe is the bottom checkbox, checked?

39cf06b3682f4be4ac7683e268f4e190

myronjoffe
Contributor III

@bentoms yes... FV2 after hibernation is a security requirement... Was going to test this evening if unticked would reproduce the issue.... Seems like you know something already

StoneMagnet
Contributor III

@myronjoffe FV2 lock is activated by booting into the Recovery Partition on the machine and requiring a FV2 enabled account password to unlock. By enabling "Require user to unlock FileVault 2 after hibernation" you're asking the Mac to reboot after the sleepimage file is written.

myronjoffe
Contributor III

@StoneMagnet I understand. So not the same as $ sudo pmset -a destroyfvkeyonstandby 1
?

StoneMagnet
Contributor III

@myronjoffe Actually I expect it to be the same (disclaimer - I'm not using FV2 in my current environment as we want network access to Macs without a user logged in), and the unlock process requires going through the FV2 login from the Recovery Partition.

myronjoffe
Contributor III

@StoneMagnet i've scripted this command in the past in conjunction with policies for FV encryption and machines do not restart.

StoneMagnet
Contributor III

@myronjoffe Kills that theory then. Have you looked at the output from pmset -g to see what exactly changes when the "Require user to unlock FileVault 2 after hibernation" option is set in a configuration profile? Perhaps it's changing something else besides the destroyfvkeyonstandby setting.

tdmac
New Contributor

I've been experiencing this in my environment for the last 5 months. I talked to my TAM at JAMF and they said its a HW issue, I currently have an open case with Apple on this as its a known issue per them. Apple gave me a workaround that is exactly that, a workaround, not a fix.

This is the current workaround from Apple that push’s off the hard sleep state of the HD with the standbydelay time in seconds. This will compromise some battery life, but it does work as I’ve had it running on mine.

The process sets the autopoweroff to “0” then you set the standbydelay to a time larger than the default of 14400 ( which is 4hrs in seconds)

From a terminal do the following:
-bash-3.2$ pmset –g
If autopoweroff is set to 1, then run, -bash-3.2$ sudo pmset autopoweroff 0
Verify again with pmset –g that autopoweroff is set to 0 now

Now set the standbydelay to a higher second count for a time that is greater than the max time you would not use the laptop and it would be asleep (days)
-bash-3.2$ sudo pmset standbydelay 86400
1 Day = 86400
2 Days = 172800
3 Days = 259200

Verify by running pmset –g that standbydelay is now showing new count

Anyone that has a true fix for this would be greatly appreciated. We do have FileVault2 enabled on our devices that is a requirement.

mpi
New Contributor III

Hello,

I appear to be having a similar situation. What was the outcome with Apple in regards to it being a possible hardware issue?

Thanks

DesktopUser
New Contributor II

Are you running Bit 9 on these systems? There is a known sleep wake crash caused by Bit 9 and FileVault.

chadswarthout
New Contributor II
New Contributor II

@dtempleton @mpi @bentoms Hey, wondering if anyone got any closer to an answer on this. We have a ticket open with Apple but still not sure why this only impacts certain devices.

carlo_anselmi
Contributor III

Hello
We are experiencing random reboots with a few MacPro 2013 with Sierra 10.12.6
We sent them back to our supplier thinking it was an hardware problem but they found nothing We have several others which works fine and all based on the same image/policies
No FV enabled
Any hint or workaround would be highly appreciated!