How to inadvertently reboot every computer and server in the Company because of this Jamf “Feature”

First off - I audit the Restart Options on every policy I create, but maybe it's because I've been using Casper Suite/JAMF Pro for close to 10 years now, so I know its there.

I believe that JAMF turns this on by default because if you do install either Apple updates or a package that requires a restart, you want the system to reboot so its not in a state that can cause crashes or problems to the end user because the update has not occurred. I've seen issues with end-users where a patch is installed and they ignore the restart and then call the Help Desk to complain about a problem, only to remote in, and see the ignored the restart request pushed to the side. Sometimes for days or weeks! Keep in mind if a user is logged into the system, the default settings should not reboot the system automatically, they'll only get the request to do it, and the countdown clock to reboot the system will not start until they press "OK" on the restart notification.

However, I don't speak for JAMF, so I couldn't tell you why they turn this on by default for every policy. But the setting has been there for a long time now. But I can see the other side of things as well.

But I also think your "reboot every computer and server in the Company" is a little overboard for the description of the problem.

Just my two cents worth.

It would be nice if Jamf offered us a way to set some "defaults" for new policies. Not every available option that's present in a policy, but some of them would make sense. This is certainly one of them. Offer us a way to have that NOT be present by default if we don't want it on for every policy. And maybe other items, like the Maintenance > Inventory collection option. I tend to turn that on for a LOT of my policies. I'd say it's well over 90% of the time I need to enable that because it's not on by default, but I'd like it to be. Frankly, there's less harm in my opinion with collecting inventory at the completion of a policy, even if it's not needed than there is in having the Restart Options payload enabled by default, which could lead to some unexpected and embarrassing, possibly even data loss level results.

The last one is just the Enabled checkbox on the General tab. I actually might like the ability to create every policy with the policy disabled by default, and then manually enable it later.

There may already be a Feature Request that asks for this. If there isn't, there should be.

Umm , again NO!
Having inventory collection by default on a policy with a recurring checkin?? WHATTT!!

Do you realise that a new record is added everytime an inventory is submitted...
The 'Applications' table grows massively.
I've seen this and had so many issues.

I like the 'update inventory' unchecked.

Just my 2 cents worth also...

I found this out the hard way.

My intention was to curate an accurate account of /Applications for each of my End Users. Had NO IDEA that the DEFAULT "Software Update" [configured] meant that when I released that Policy to "Recurring Check-In" /Target Computers = All, that every LAPTOP, WORKSTATION AND SERVER would undergo a forced software /security reboot because of an inexplicable, unnecessary DEFAULT NEW POLICY setting?

Thanks, JAMF. You could have made this clearer-er in the documentation with BIG CAPITAL RED LETTERS. Especially since this appears to be a DEFAULT setting within each NEW Policy.

I can endure the humility and hit to my reputation, but the implications are far-reaching and could have been devastating.

@taugust04

But I also think your "reboot every computer and server in the Company" is a little overboard for the description of the problem.

But that's what happened. I had all my 20 systems reboot. Luckily, it was just my test lab, but had this been a production environment, well it would be one of those situations that you dont' want to have. I wasnt trying to sound like an alarmist, this is a serious design flaw in a management solution that is supposed to be helping me do my work, not the other way around. This feature is not a positive service, its more of a disservice.

If an MDM has such a powerful setting as default, and you need a decade of experience with the product, to know about it, then that is bad design my friend.

I believe that JAMF turns this on by default because if you do install either Apple updates or a package that requires a restart, you want the system to reboot so its not in a state that can cause crashes or problems to the end user because the update has not occurred.

JAMF is a tool, it should not be taking decisions like this without letting me know by default. The correct way it should work is by knowing the files need a restart, so maybe if the payload to Restart is not active, then it could do a red banner or a pop up of some kind to remind me that the policy might not work as intended unless there is a reboot.

I think there are two issues at work here. One, I fully agree that Jamf really should try to refrain from making default decisions for Jamf administrators, when possible. It's only my personal opinion, but I don't feel like putting this option in by default is a great decision, because it's making a default decision for admins who may want to do something entirely different. I'm not interested in discussing what is considered best practice here. Everyone operates in their own unique way, and every environment has its own needs. Jamf shouldn't be in the business of making decisions for anyone up front on this stuff.

The second issue is that the Jamf UI leaves a bit to be desired as far as clarity is concerned. The problem is, when setting up a brand new policy, it's actually not easy to distinguish between payloads that are configured versus ones not configured, other than looking at the small text below the payload name. That's really the only indication someone has that something is already configured. Jamf should look at providing a more clear indication of what has been set up (by default or by an admin) Here's one example of how they can do this. Simply put a checkmark next to payloads that are configured. Here's a screenshot mockup.

Notice that General and Restart Options both have a green check at the end of their rows. This makes it very easy to see those are configured, versus others that aren't. There are other options to consider as well. Instead of a checkmark, the labels for the configured payloads could be bolded more or made a darker text color, like black even, to indicate something is going on with them.
I guess what I'm saying is, for new Jamf admins, it's very easy to not see that the Restart Options payload is configured in a policy because there's very little that makes it stand out against all the other payloads. Make it more clear and it could go a long way toward preventing unwanted actions from taking place.

While I'm at it, can I ask why Packages, Scripts, Printers, Dock Items Local Accounts and Directory Items all have a "0 <something>" under their names, instead of saying "Not Configured" like all the other items? Those are not configured, by default or by me in this screenshot, so why doesn't it say the same thing as other unconfigured items? You see, it's the little inconsistencies and annoyances in the Jamf UI that really get me. There's no reason those should say something different than other payloads if they are not configured. Right?