Jump to content

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


sean_a
 Share

Recommended Posts

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.

  • Like 1
Link to comment
Share on other sites

  • Moderators
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

Link to comment
Share on other sites

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 by sean_a
Link to comment
Share on other sites

  • Moderators

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. 

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...