When to use 'Update Inventory' on Policies..

kerouak
Valued Contributor

Can anyone shed light on When to Update Inventory and when not to in a policy.

I figure that 'Ongoing' policies should not have 'update inventory' checked..

What do yo all think??

ta

20 REPLIES 20

CasperSally
Valued Contributor II

You need to think about it for each policy. It's really dependent on the situation.

For example, all of our ongoing policies are to install software to X users who don't have Y piece of software. We have to put update inventory on for all of those policies so that once they get Y software in the policy, inventory updates and then they fall out of the X user smart group so the policy stops running for them.

The X smart group is built to be users we want to have software that don't already. This allows us to leave the policy ongoing because we have various policy install failures when students close laptop lids, etc.

cmarker
Contributor

Really the big one you want to avoid is when you an Execution Frequency of "Ongoing" AND a Trigger that happens regularly such as "Startup" "Login" "Logout" "Network State Change" "Recurring Check-in".

Unless your clients are enrolling regularly "Enrollment Complete" isn't bad. And custom triggers can be used as long as those custom triggers aren't being called over and over again by another policy with one of the above triggers.

Personally, I have most of my Self Service policies do an Inventory Update, and many of them are set to Ongoing.

corbinmharris
Contributor

Update Inventory for all software installations from Self Service. This allows smart groups to update when a software package is installed. I have an alternative SS policy that shows 'INSTALLED" over the software icon if the software is current. Users can still re-install the software if the currently installed version is "broken", so it is set up as an ongoing policy.

Corbin

Chris_Hafner
Valued Contributor II

This is a great question and as you've seen there are some really good yet varied opinions. Just remember what is does and why you're running it. As a general rule however, the answer is: "As little as possible." or "only as often as required". I'll admit that I'm a bit inventory/recon heavy as I use a number of smart groups to populate software policies. So, in order for a user to populate in or out of a smart group an inventory/recon needs to be run somewhere. I run a recon at the end of any software install in which I need to have a smart group updated. Much like @CasperSally mentions.

I will however, disagree slightly with @corbinmharris statement. Well, only so far as to say that there are often other ways to deal with that type of methodology. For example, one could always have an original install policy set to "once per computer, etc" and then have a separate ongoing "re-install" category which would require no inventories at all. Yet, it wouldn't provide the same icon location as he mentions (install vs uninstall). Now there may be great reasons why @corbinmharris doesn't want do that and I won't even begin to tell them that they're wrong for it. I just want to point out that there are often many ways to accomplish almost any task.

Regardless, just have an honest conversation with yourself or your team to make sure that it really makes sense. Here two very simple examples. 1) Our printer policies do not have an inventory or recon process associated with them as my users may want to uninstall or reinstall them often time for no reason other than to feel better about it. I also have no smart groups based on installed printers (I would use a script for that in a policy if I needed to). So, installing any printer queue here takes only seconds as opposed to 2-4 min with an inventory/recon attached to it. However, say I need to install Skype. I don't want to install it for users that already have it, especially if it's up to date. Since I base this policy on a smart group, my Skype policy has to have a recon process attached to it which forces it to run immediately at the end of my Skype install, there by removing the policy from Self-Service immediately!

Now here are a few small caveats. Such as the fact that JAMF has modified the inventory process to run after a policy or group of policies so that the inventory process is invisible to the end user, as it's not attached directly to the policy. It will also run after a "group" of self service policies that may each, individually require an "inventory". At least in version 9.x and newer. Since that doesn't meet my needs I use the "/usr/local/jamf/bin/jamf recon" in the "execute command" area of a policy that needs to update immediately. This is FAR less efficient than the way JAMF has begun using the inventory as part of a policy.

With all that said. I know for a fact that almost all of use have a standard "inventory" process that runs an inventory once a day. This is advised and is ongoing, but limited based on the overall needs of your organization. Personally, I've beefed up my servers specifically so I could abuse the recon process a bit in order to provide my users with a really outstanding "Self-Service" experience.

P.S> It's nice to finally have a free moment to write something here on the Nation! I've been missing you all!

Taylor_Armstron
Valued Contributor

A little bit of a hijack, and I'll likely create a new thread for this as well, but anyone seeing issues with the inventory NOT updating? I'm using it for exactly the reasons that Corbin listed - all of our "Test" software goes to Self Service, scoped to smart groups, most of which are based on EA's. We're seeing some software still being advertised. Do EA's update with inventory, or does that require a full recon?

bpavlov
Honored Contributor

@Taylor.Armstrong As far as I know, EAs update with inventory. If it's not, then sounds like something else is going on. Is it just some EAs not updated? Or all of them not updating? Do they update only after doing jamf recon or do they update after running a policy with an inventory update as well? Either way, it doesn't sound right and I'd reach out to your JAMF Buddy.

Taylor_Armstron
Valued Contributor

Thanks @bpavlov. We're still basically standing up our JSS, so I'm still trying to get the helpdesk trained on exactly what info to report up. In other words, exact situation is still murky :) I'm using EA's for versioning info on must "plugin" type packages (Silverlight, Flash, Adobe Air, etc.) and those appear to be the ones most of the reports are coming in on. I think we may be using EA's where they're not really required though - ex. - Firefox, where I SHOULD be able to just pull the version directly. I suspect it may be a timing issue. All I know so far is that if I run a full recon manually, it appears to "fix" the issue. I'll start up a new thread if I can't figure it out. Appreciate the response!

cwaldrip
Valued Contributor

OT: @corbinmharris I love the "Installed" idea. steal!

Look
Valued Contributor III

I only use it if I need a smart group updated really.
The other thing I have is a group for machines where the inventory is more than a day old and I run it against that daily, basically it garuantees at least a daily inventory, but only if some other process hasn't already run one.

rcram
New Contributor

A potentially big consideration in inventory collection is the total size of your client pool, both current and projected. If you are managing a relatively small number of machines frequent inventory checks (EX: more than once a day on a regular basis) may not be an issue if you have a beefy enough infrastructure to handle the overhead. When I started out I had less than five thousand machines being managed. Multiple inventory calls to populate Smart Groups worked very well from both a management and a server stability standpoint. As my client pool got larger and larger I had to modify my procedures for using "Update Inventory" to avoid pancaking my JSS core. Now that I am clocking over 35,000 machines I have to be very careful about which policies collect inventory and the frequency these policies run. Sometimes (most times lately) the interests of stability trump optimal inventory collection.

corbinmharris
Contributor

@cwaldrip Thanks! I stole the idea from another JAMFer a while ago.

Attached is a screenshot for reference -

c1cc1a9527a8497eb15c12aa3f103cc4

Chris_Hafner
Valued Contributor II

That does look pretty cool!

kerouak
Valued Contributor

Cheers for all your input..

Now then, I've found a policy which is set to Trigger at 'recurring check in' and excecution Frequency of once per day...

Now, We have a script which deletes the logged on users account at Logout, so there are no user accounts present.

Surely, I don't really need this if the Specific Policies are set to 'update Inventory...

YES / NO???

Thanks again !!

Chris_Hafner
Valued Contributor II

The question is: Do you KNOW that one of those policies will run in a given day. If so, then no, you probably don't need a separate policy. We look at this the other way around. If we have a daily inventory then we do not HAVE to have a policy run with an inventory unless there are other reasons for it. In the end, it's all about making sure you get an inventory regularly, but otherwise as infrequently as is reasonable.

kerouak
Valued Contributor

Most of the policies Im looking at are 'At Login' So, When a student logs in, The policy runs... They are all set to update inventory.. I'm sure this is not required..

To put you in the know, I'm addressing large Database Issues on our JSS....

TA!

Chris_Hafner
Valued Contributor II

Fair enough. The only comment I'd make at that point is that, that tends to slow down login times and will not give you data on anything happening with the user account at all. What I mean is, if you're deleting accounts at log out, and inventorying at log in, you will never be able to inventory any info form said user account. If that works in your situation then great. Otherwise, I would run the inventory at logout, prior to deleting the user account. I tend NOT to use either login or logout policies unless necessary as they delay those, usually quick processes. When our users experiences a slow login or logout then tend to get cranky.

kerouak
Valued Contributor

Well, If they don't like it, They can go to another Uni!!!
lol

Chris_Hafner
Valued Contributor II

I suppose that's one way to look at it. Just remember that there will be a gap in your inventory info. Since you're managing the user accounts much like shadow volumes on an old tripwire system then it probably doesn't matter.

dstranathan
Valued Contributor II

Im a self-admitted JAMF noob. I would usually agree with @Marker.43 but there are cases when a reoccurring event such as "Login" combined with a Frequency of "Ongoing" might make sense regarding updating inventory...I think.

I have a printer mapping Policy that is triggered at "Login" and has a frequency set to "Ongoing".

It looks to see if the Mac is in a "Missing Printer - Dept XXX" Smart Group.

If the Mac is NOT the Smart Group, then the Policy does not run (i.e.; printers do not need to be mapped).

If the Mac IS in the Smart Group (printers are missing), then the printers for that Mac's department are mapped. Also, if this Policy runs, then it updates inventory too (makes sense - I want the JSS to know that the Mac now has the printers mapped, and therefore is will no longer be in the "Printers Missing" Smart Group any longer.)

The JSS doesnt get spammed with inventory updates all the time. It only occurs when Macs are missing printers - which is very rare as my users dont mess with the OS X Printer pref pane, dont log in/out very often, and IT Dept rarely moves/addes/changes printers.

Is this sound logic on my part?

davidacland
Honored Contributor II
Honored Contributor II

@dstranathan In this case it sounds ok. Although it's ongoing and at login, the restriction is the smart group and as you said, update inventory is needed once the policy has run to confirm the printer is mapped.

We use the same logic for some software installs, with a "should have it but doesn't" logic on the smart group. Without an inventory update, the policy would keep running over and over again.