Default "Restart Options" Policy Payload Bug/Conflict w/Other Policies

[pcrandom]

Just noticed something, not sure if by design or bug...

I know JSS is smart enough that if, say, a "sudo jamf policy" will execute multiple policies one or more of which may require a restart, it waits and only restarts once at the end of all the policy executions. But it appears that whichever policy it executes last (and we have little control of the order), when the "Creating Reboot Script..." step occurs, it uses the Delay value of that particular policy, even if the package or update in the policy doesn't require a restart.

Since that might be difficult to parse, even for the person writing it, to illustrate:

Policy A installs A.pkg, which requires a restart. Policy A's restart delay is set to 15 minutes.
Policy B installs B.pkg, which does not require a restart. Policy B's restart delay is the default 5 minutes.

Both policies are set to "Restart if a package or update requires it" and scoped to a computer that, when "sudo jamf policy" is run, happens to execute A first then B. The expected result, in my opinion, is that after B runs a restart prompt for 15 minutes will pop up. Instead a restart prompt for 5 minutes appears.

Has anyone else seen this? The reason I caught this is because in our environment all of our policies that we think may require a restart (think Apple Software Updates) are set to a 15 minute restart delay, but I noticed that after one of those policies executed, I was prompted that my computer would restart in 5 minutes, because other policies were also executed at the same time that had the default 5 minute delay, even though the packages in those other policies didn't require restarts.

Since all new policies has the Restart Options payload added by default with "Restart if a package or update requires it" for both if user is logged in or not, and a default delay of 5m, this is a potential headache. If I want to avoid this issue from happening, I'd have to remember to remove the Restart Options payload from every policy that doesn't need it.

[bentoms]

@pcrandom Interesting, I've seen jamf collate gather inventory actions.

So if you have 3 policies with gather inventory running at the same time, only one gather inventory is called.

But, i'd reach out to your TAM @pcrandom to clarify if what you're seeing is right.

[pcrandom]

Thanks @bentoms, I just sent an email to Support. It's very strange. When multiple policies with the Maintenance payload and Update Inventory enabled are run, our JSS does properly delay the multiple inventory requests until the end and runs inventory only once, so at least that part is working.

I should say the original scenario I described isn't exactly what's happening. The overriding of the Delay time seems to be, in our specific case, when Policy A is a Software Update policy and installs an Apple update that requires a restart. It prompts for restart after both policies execute but uses the Delay time of Policy B.

In the original scenario I described above, where A.pkg in Policy A requires a restart and B.pkg in Policy B doesn't, I'm actually not getting a restart prompt after A and B execute, so the issue is worse than expected. (I should clarify, when I say in my original test that A.pkg requires a restart, the package itself doesn't need a restart, but we've set it to restart in the policy if user is logged in. It shouldn't matter, but just to be clear. And if Policy A is run by itself, it does prompt for restart and has the expected 15 minute delay.)

[pcrandom]

Word from our TAM is that this is a known Product Issue, PI-002579. "As you found, if multiple policies are set to perform a machine restart, instead of queuing up one restart at the very end of all policies, it is instead being reset or not respected at all. We would advise that if multiple policies are running at the same time, simply adding a restart to the last policy run, should trigger the restart and give us the expected results."

This isn't a great solution since we don't have a homogeneous environment and we scope policies based on smart groups for whether a computer needs a particular policy applied, so the "last policy run" might be different for each system. Hoping for a more permanent fix in the future. Also, really wish there was a way to look up known defects and product issues before devoting time to testing and documenting a bug I "discovered" that ended up being already documented...

[were_wulff]

@pcrandom

We have a Feature Request for a tracking system for known issues here.

Feel free to vote it up (I know I have!) and comment as well. :)

Thanks!
Amanda Wulff
Jamf Support