Policies that update inventory on all computers cannot be set to ongoing frequency at recurring check-in.

Yep it's one of the protection features that was added a few versions ago. Some people don't mind it, others have reacted badly.

It's limited to the all computers group so if you target a smart group that says "should have software X but doesn't", that will work fine.

It sounds like still targeting all computers, but using an exclusion, is the issue here.

I just moved 'jamf recon' command to Files & Processes -> Execute command. Seems odd that Jamf is trying the idea of protecting us from ourselves. While I can still run an installer at every checkin on a computer.... Where do you draw the line?

Recon has one of the highest cost of resources, so having it ongoing at check in is typically not advised, what is it you are looking to accomplish?

The issue isn't letting you run an installer at every check-in, like @tlarkin said, recon is really intensive, not just on the local end but for the server as well. I've set a policy to do an inventory at check in (but only once per computer) on our entire Mac population, "only" around 600+ systems and the JSS slowed to a crawl.

What software do you want to install every 15 minutes (or whatever your check-in interval is) over and over again on the same computers? Use a smart group, like @davidacland said, scope it to include computers that don't have the software you want to install, and use that for your target instead of all computers. Then when it installs the software and runs inventory, it'll detect the software is installed (if it's successful) and drop the computer from the smart group. You can still set that to ongoing though practically speaking it will only run once per computer unless you have a lot of failures.

If you need to have live data determine an action and don't think that your JSS data is accurate or current enough to scope, use a script that runs a live check and calls a trigger policy if the requirements are met. Scope it to all systems and let it do its thing without the massive inefficiency of excessive recons.

I guess it depends on how frequently you have machines check in, but having it check in on every check-in seems like overkill O_O

Might be better to have policies that do things that would require a smart group update to keep from re-firing to run inventory with that policy, rather than having machines running recon every time they check in. Just my two cents.

As I use a scope exclusion to avoid hitting computers that don't need modification, I'm not worried about load on the workstations or server.

The bigger idea here is that JAMF is trying to take the position of protecting us. I'm just saying that's a slippery slope. There's thousands of ways I can screw up my machines by running a policy in a loop. Why choose this one to limit me?

@thoule as I mentioned above, running mass inventory in the past has slowed down my JSS, which is running on fairly standard servers, nothing special but not underpowered, and I'm managing only triple-digits in Macs. Perhaps this is more about protecting JSS performance and stability than mucking up your own machines.

I really have no issue with JAMF protecting my JSS from my own foolishness. When things are done to improve security and stability for everyone I can definitely live with it, especially as they aren't really preventing you from performing the task you want, just making sure you are doing it in a manner that doesn't put the JSS at risk.
For example what happens if there is an OS or App update that for one reason or another breaks the extension attribute(s) you are using for exclusion, suddenly you have every computer elligible for the policy every checkin forever AND updating inventory every time, this will bring your JSS to grinding halt in no time.

Soo I finally get to be on a more up-to-date jamf environment and I am seeing this "protection".... I have the same workflow as @thoule Compliance policies scoped to all machines, excluding any machine that currently meets compliance, running ongoing at check-in with an inventory update to pull it out of compliance.

I understand warning someone that this may be a bad idea if not set up correctly. But to outright block it is not good.

and to take @Look 's reasoning for why this is good, if We invert the structure away from scoped to all and excluding installed, over to scope to missing and exclude none. Now if the EA breaks it will either be in the exact same boat as it will see all machines as being in need of the install, running forever at every recurring checkin, or no installs will happen at all, resulting in required installations not running and machines being unusable if it is a NAC or VPN solution that was being installed by policy.

I get that they see it as a "Save yourselves from yourselves" type thing, similar to rm -rf / being blocked in scripts and in files and processes. But one of these WILL destroy a machine and the other MAY, if you don't know what you are doing, cause a little strain on your JSS and slow things down. I'd much prefer MAY situations to not lock down options. But WILL situations can and should be blocked.

I am also just moving the inventory update down to files and processes so that I can no longer have it blocked.

I've found that using control scripts for most automation is better than relying on inventory data. There are several reasons the inventory can be wrong. We recently had an issue where our applications table crashed and all systems were reporting no apps installed (until I truncated the table and allowed it to repopulate), which would have caused a lot of systems to reinstall a lot of apps if not for our control scripts which run verification before taking action.