Being able to do a full asset sync is only useful if the technician is aware that a change has happened, but the change hasn’t showed in the Syncro WebUI.
If the change has happened and the technician is not aware of the change, then the technician will be making decisions based on the incorrect data in the Syncro Web UI.
Being able to trigger a full asset sync is definitely not a solution.
It is a bandaid at best.
Easily and processing are not the same thing though. Even the event policy ones can still reach into the 100,000 range. The storage part again is in the mbs of data. It has little amount of storage needs because its all text and not object base. Its whatever you want to think and also an example of how something that sound simply still takes CPU cycles. Even if its not at the server level - its happening at the client level and that means less resources for the client as you still have to gather said data (keep it in ram), process said data (CPU/format the data) and then send that data (network) times x amount of clients you have. Its not hard to see that it can be very intents if all clients were being updated very quickly. Some task can happen sooner than other of course witch is what I pointed out already.
While this thread doesnt affect me directly - I am just saying andrewd is right, but I dont think we can make it all happen quickly for everyone. It would be best to set some task sooner than others though ( Pending Reboot, Last Boot, Device Name, and Network Information) and/or have some type of flag that might force more updates (or shorter delay) while looking at the asset or client (so it doesnt force update everyone at once - but again that is kind of what the sync button does already).
I know - I wrote an RMM before xD so I do have some background in what might be going on:) The real question is what is the server doing when it updates said information that might be taking more cycles?
Why? You were doing so well Andy. I was thoroughly enjoying the discussion and learning as it went.
IP Address is a great example. IP addresses don’t change all the time, not even close, but it’s a critical piece of real time data to us.
I’ll bet I could list 10 things that update quickly of less importance to us if we had that list of the update times for everything. This thread could become a well thought out and very specific feature request that basically maps out how to do it, using less of your resources and more of the collective intellgence you have in those 4000 MSP’s. What a resource to draw on…
Please add this to your online Syncro documentation.
I’ve made this request internally. I agree it needs to be documented in our KBs.