Update Inventory

[Sobchak]

1. How much bandwidth and/or system resources does running the update inventory policy take up? Are there concerns about the frequency you set?
2. Does Casper have the ability to schedule hardware inventory and software inventory separately?

[mm2270 · Accepted solution]

I don't think bandwidth is any concern, when talking about traffic between the JSS and the client. The actual inventory submission is relatively small in size, but will partly depend on a number of factors, like:
• Are you collecting fonts and plug-ins?
• Do you have a large number of Extension Attributes?
• Any additional application collection paths?
and so on.

As for client side resources, that can be a little more of a concern, but in recent updates to Casper, JAMF has worked on addressing some of the big issues, such as multiple inventory collections happening one after the other based on a policy trigger, like "check-in" Still, recons can be a little disk and CPU intensive at times, so you probably don't want to be doing it excessively.
Another reason not to do it excessively is that each submission per client takes up space in the db and is saved as part of the computer's history, viewable in the JSS. If you do find you need to do frequent recons, you'll want to look at lowering your log flushing threshold to happen more frequently to keep the database happy and nimble.

As for splitting hardware and software to different times, no, not possible currently, and it may never be possible. See this Feature Request:
https://jamfnation.jamfsoftware.com/featureRequest.html?id=78
JAMF is concerned about not doing complete inventory submissions each time it happens because of the possibility of inaccurate Smart Groups. Its entirely possible to have a SG populated based on both hardware and software information criteria, so I can see the concern about allowing those two types to run separately and them being out of sync.

Hope that helps.

[ImAMacGuy]

we do inventory updates constantly, and apparently it's been causing issues with our DB of late. I guess it was over 59million lines under the applications table alone, and that's purged every 6mo. We have to monitor it very closely as around that size it was causing issues with the DB crashing.