Skip to main content

Seeing a small, but not insignificant number of machines that seem to get stuck updating inventory. Most are remote systems, often on slow WAN links, and it seems that it simply times out during the recon phase, but never completes. Regular policy check-ins seem fine. For example, from one of our machines in Hawaii:



Last check in was this week (machine is a laptop, so I don't expect it to be online 100% of time), but last inventory update was 2+ months ago. Needless to say, this is causing issues for patching, smart groups, etc.



In the limited testing we've done, it seem that re-enrolling usually clears things up.



Before I try writing a script myself, anyone have anything that would take the dates from Last Inventory Update and Last Check-in, and populate a group based on a defined difference? We normally do an inventory update daily, so I'm thinking something like "if last check-in date - last inventory update = more than 2 weeks, re-enroll" or something along those lines. Haven't gotten much further than that, but figured I'd check before starting to try to script it.

You can just use the Last Check-in and Last Inventory Update date criteria to get these machines. For example, use something like this



Last Check-In | less than x days ago | 6

and

Last Inventory Update | more than x days ago | 30


This gets Macs that haven't submitted inventory for at least 31 days or greater, but have checked in to your JSS within the last 5 days. I actually just ran an Advanced Computer Search on our JSS right now with the same criteria and it pulled up 12 machines in this state. So you're not the only person who experiences this in their environment, for what its worth. :)



Edit: If you want to use a 14 day (2 week) difference as you mentioned, you could change the first one to 14 or 15 instead of 6, or keep it at 6 and drop the Last Update one to 21 for example.

Thanks Mike. Funny that I never considered just using the normal JSS options to find the info - was jumping straight to "going to have to script this".



Looks like the problem isn't as wide-spread as I feared, which tells me that most machines I've noticed it on in the past eventually fixed themselves. Like I said earlier - re-enrolling seems to fix it, but I suspect that the real "fix" is probably flushing the cache of old reports, or something along those lines. Now that I've isolated which machines are affected, I'm going to experiment a bit to find the best option for fixing it.

Reply


Terms & ConditionsCookie settings