restarting service on FW server = do all clients re-submit inventory?

[sean_a]

Is there a way to get all clients to re-submit inventory?

Would restarting service on filewave server do that?

[Pierre-Nicolas]

Restarting the server should not trigger mass verify / inventory report.

Inventory report is triggered locally by desktop clients and via persistent scheduled task (persistent means it will resume as it was before restart) server side.

You may be able to trigger a mass verify using the API:

/api/devices/v1/devices/verify

takes a list of client ids (which can be fetched from other API call) and triggers verify, which in turn triggers inventory report.

I'd just be careful using it too often as this may cause some load on your server if all devices report in a short timeframe.

Clients are designed to wait a random time before reporting (based on tickle time), APNs are not all sent at the same time, Android EMM is also working based on batch size so the load will be spread, but it will nevertheless impact the server if you do it too frequently.

[Josh Levitsky]

On 10/10/2022 at 4:01 PM, sean_a said:

Is there a way to get all clients to re-submit inventory?

 

Hi @sean_a can I ask why you want them to do it? Is it because you are doing something to all your devices outside of filewave like upgrading all their RAM and you want the inventory to be updated sooner? Or is there an issue where the inventory seems wrong for some devices? I ask because clients will do a Verify every 24 hours so the data in theory should become correct fairly quick, but I wasn't sure of the motivation to do it which might make the answer better. 

-Josh

[sean_a]

The reason for this request is an acknowledged edge case. In this case, I deactivated an association (pkg fileset), with the unintended consequence of deleting the software from clients since there was also a pre-uninstall script in the fileset, so the pre-uninstall script ran as clients left the association. I corrected my mistake fairly quickly, though I wanted all my clients to see my correction as soon as possible, even if doing so would put potentially put some load on the server. In retrospect, I did not need to force an inventory to all clients, because it seems the clients picked up the correction soon enough as the number of "uninstalls" was relatively low.

(Nothing like a Monday when you accidentally start deleting VPN software from laptops.... muhahahaha....haha....sigh.)

Edited October 12, 2022 by sean_a

[Josh Levitsky]

Thanks on that. I was thinking that the 2 minute default tickle would play a part in this and devices realizing something changed. It's one reason I might make the tickle a larger number to have things seen after a bigger interval than 2 minutes but also at the same time that short interval means when you make a correction it'll be seen quickly too. What PN mentioned about using the API to send a verify would be a way to ask the devices to do things like update custom fields and all the many things that happen every 24 hours in a normal verify but quickly. In your case the 2 minute tickle I think made things happen quickly because detecting a model update is in the tickle.