Update inventory after policy runs: Best Practices

[duffcalifornia]

So, I've heard a lot of conflicting information on how often/what types of policies you should have an "update inventory" payload run when completing a policy - it can be nice to have the information accurate, but it also creates a LOT of logs and can potentially unnecessarily bloat your MySQL database.

What are your best practices around updating inventory with all/certain/no policies?

[were_wulff]

@duffcalifornia

In Support, we generally only recommend a policy update inventory when it's absolutely necessary and the inventory update cannot wait until the next regular check-in of the device.

One example of that would be, say, a policy that's scoped to a smart group in which computers in that group do not have a certain piece of software or are on an old version; in that case, we might want the policy to update inventory so the computers fall out of that smart group immediately to give the group a more real-time accurate count.

In some environments, that may be considered absolutely necessary, in others, it might not be such a big deal.

What "absolutely necessary" is can vary widely from environment to environment, so there are really no 'best practices' from our end in that regard as everyone's environment is different.

Amanda Wulff
Jamf Support

[stevevalle]

We run all our Self Service policies based on smart groups. ie. If the software is installed on that computer, exclude it from displaying in Self Service.

Therefore, all our Self Service policies include an inventory update to remove the app from Self Service once installed.

We also set our check-ins to every 30mins. If we need a computer to check in before that, we can force it by using Casper Remote.

[Look]

We have a smartgroup of Last Inventory Update more than 1 day ago.
We then scope this to a inventory update set once per day.
Every machine inventories once a day, however if you manually inventory for a specific policy this immediately gets pushed out to 24 hours from that time.
We then only have inventory update on 3 or 4 policies that really need it (i.e. they might get run more than once a day for whatever reason and they cannot be run more than once).
Seems to work very nicely.

[donmontalvo]

@amanda.wulff this is good stuff:

In Support, we generally only recommend a policy update inventory when it's absolutely necessary and the inventory update cannot wait until the next regular check-in of the device. One example of that would be, say, a policy that's scoped to a smart group in which computers in that group do not have a certain piece of software or are on an old version; in that case, we might want the policy to update inventory so the computers fall out of that smart group immediately to give the group a more real-time accurate count. In some environments, that may be considered absolutely necessary, in others, it might not be such a big deal. What "absolutely necessary" is can vary widely from environment to environment, so there are really no 'best practices' from our end in that regard as everyone's environment is different. Amanda Wulff Jamf Support

This is why I love @amanda.wulff's posts...sold best practices combined with good old common sense. :)

Where a policy might be scoped to membership in a group, I can see where if you're a member of a group, you get the policy, and then you shouldn't get it again. But to her point, inventory wouldn't be necessary if the policy is set to Once per computer, which I'd imagine is the majority of policies.

For example, you need to deploy Firefox ESR 45.7.0 to computers that have 45.6.x or older. A computer falls in to scope by falling into the Smart Computer Group (SmCG). It gets the policy, and the policy never again runs on that computer, because the policy is set to Once per computer. If for any reason you need to rerun the policy on that computer, you'd flush the policy log for that computer and then BAM the computer is in scope again.

I can see where Once per computer will not work, like where an application can only be installed if a user is logged in. Like that horrible Adobe AIR crap, which comes with a "silent install" workflow that doesn't work if no user is logged in, which according to Adobe is "not a functional break.". This falls under "As long as my boss doesn't find out, and I still have a job tomorrow, I don't see a problem" category.

...so the policy fails, and never runs again, since it was set to Once per computer. This is where a Once per computer if successful frequency option would absolutely rock. :)

OK, I know what's coming...I know...I'm off to Feature Requests to vote up @brent.buckner's Policy Execution 'Once Per Computer, If Successful' feature request.

Don