How often do you update inventory?

[adambjerke]

Hey All,

I was curious on how often you have your end points updating inventory? I know it is different per workflow per environment but on average. If you could list the scale of your environment that would also be helpful

Example: 10 inventory updates per computer per day

Larger companies may aim to have lower averages to reduce load.

We are seeing poor performance and are trying to determine if its our average recons that are contributing to the poor performance.
12 inv updates per computer per day.

Any insight would be grateful.
Thank you

[mcrispin]

Once per day per computer, and whenever a device reboots. I think most would agree that 12 is a bit too much. I also don't bother with collecting home folder sizes, application usage or fonts, and I don't collect hidden accounts nor processes, unless there is contagion in the environment.

[wildfrog]

As standard we collect once per day. However, at the completion of many/most policies we also add an inventory collection. So in practice, it’s often more than once a day. That said, we do have a policy so the user can do an on-demand from with Self Service.

Additionally, we also leverage MunkiReport for additional information gathering and that runs approximately every hour.

[sdagley]

+1 on the opinion that 12 times per day is excessive.

In my current environment recon is run as follows: standard inventory policy runs once a day, any policy that installs something, user initiated via Self Service, and after the Mac restarts if the build number of macOS isn't what it was the last time the system restarted.

[wildfrog]

In fact, if memory serves, your JSS will go out of its way to try to prevent you from running inventory collections too often. For example, if you try to add an inventory collection to a policy with a Recurring Check-In trigger and Execution Frequency of "Ongoing", your JSS will likely balk at that.

The other consideration besides the performance hit on the endpoints, if you have your endpoints collecting inventory as often as you say, your DB is likely to become quite bloated.

[sdagley]

@wildfrog The restriction on policies doing a recon with recurring check-in frequency only applies if the target scope is All Computers. If you specify a Smart Group which is scoped to Managed IS Managed you don't trigger the restriction.

[alexjdale]

Once per day, and as part of policies where we want inventory updated immediately after. If we had every computer online during business hours submit inventory in the same hour, our database would be overwhelmed and policies wouldn't process. I know that because it's happened a few times.

[bilal_habib]

Every checkin, we have EAs indicating the health of CrowdStrike Falcon.

If there was just a way to update EAs only I'd go for it

[mschroder]

We do it once per week, plus whenever the user has executed a Self-Service policy (for the majority of policies).

[wildfrog]

@sdagley So if I understand what you said correctly, you can in fact create a policy that executes at recurring checkin, on an ongoing basis, just so long as you scope it to a group or individual machine(s) - i.e. not ‘All Computers’?

[wildfrog]

Because my understanding is that the restriction is triggered by the combination of the ‘recurring checkin’ policy trigger with a frequency of ‘Ongoing’ rather than anything to do with scoping.

[sdagley]

@wildfrog No, the restriction is specific

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

If you change the Scope Target from All Computers, to Specific Computers and use a Smart Group with Managed IS Managed it will allow creation of the Policy.

[dgreening]

We update inventory for any Macs which have not done so in the last three days. There are some groups which get inventory updated on a daily basis, but the standard is three days. We have a large fleet (tens of thousands), so we are somewhat conservative about inventory update due to DB bloat.

[wildfrog]

@bilal.habib We use MunkiReport and when combined with Munki, MunkiReport reports at the end of each Munki run - every hour or so. But since we're not running Munki, and still want MunkiReport to report every hour, we needed something to trigger it on a more frequent schedule than Jamf's policies allow. The MunkiReport folks developed a script for this - MunkiReport Checkin
This script runs at every recurring Jamf checkin and looks at the MR log file to see if it's more than 60 minutes old. If it's more than 60 minutes old, then it tells MunkiReport to check in.

I wonder if you could do something similar where you'd trigger a recon if the file that Crowdstrike appends its data to is older than a specified threshold.

[adambjerke]

You all have been incredibly helpful thank you.
Yes the average of 12 was based on how many recon we are seeing on the server divided by how many computers we have.
So that would include computers that are being provisioned which may recon more than normal. But saying that it would also include computers which may be incorrectly scoped and rerunning policies with the recon payload.

Example: Reinstalll Antivirus
We have a policy that will reinstall our antivirus if Jamf detects that the end point does not have it installed. This type of policy will be set as ongoing. The same policy would have the Update inventory option set so it will update jamf to then remove the computer out of scope so the policy doesn't try and push the policy again on next check-in because it still believe the device has no antivirus.

We have a handful of these types of policies, but they should be occurring that often... so its making me think we should sure-up our scoping and smart groups.

Do you use Ongoing or Once per computer more?

[G_M__webkfoe_]

@bilal.habib

That should be easy.
Just run a script that checks for the needed information (instead of a recon), and through API (curl) you'll update the EA record.

[walt]

@G_M__webkfoe_ do you have any resources on setting something like this up? sounds like it could be useful