Jamf agent might be causing my users to reboot during sleep

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.

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

@dtempleton Are these fv2 encrypted?

@bentoms Yes... What you thinking?

@myronjoffe is the bottom checkbox, checked?

@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

@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.

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

@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.

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

@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.

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.

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

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

@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.

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!