So in reality, we probably need architecture in place to be like I only care about this RMM alert if it’s fired against the same asset X times in Y duration. Since that architecture doesn’t exist today, I am trying to find a stopgap where we might be able to deliver some additional value here for this use case without the core architectural changes. I’d have to discuss it with engineering in either event to get a scale and scope of each, but I’d lean toward providing this value now vs a bigger change getting scheduled but no value delivered for a good amount of time.
But to answer your question, yes, this would definitely address these concerns using this method.
@Andy This is only really a UI thing but when you manually select install for an update it shows as “Installing” however if you go off the page it will give you the option to install again.
Be good it still showed as installing even when you come back to the page and then “Failed” if you know it failed.
Good feedback. I made a note. Now when it installs it will be moved over to the correct area (like recently installed or failed) so basically clicking install again before it completes installing would have no effect at that point.
One improvement we are making as part of this is that changes should update much quicker, like when something does move from missing to recently installed, for example. So it’s not in the “big sync” anymore, it’s now part of a more rapid cycle.
Agreed. I usually go to the scripts page and watch, but it doesn’t stick there, either, so it’s not apparent if the update fails or not, you can just see it’s in progress, which does seem to match up with processes running on the endpoint you are trying to install to.
Maintenance windows can also be utilized by scripts, where you can predefine a window for a client and then just tell the script to run during that time. There there are no guesses on who can have stuff rebooted at what time.
I’ve asked for this before but it hasn’t had much traction. Seems like a much simpler way to manage a large subset of assets.
I was wondering if you have any awareness on when Syncro will fix the issue with not supporting HTML as a standard format for Tickets and why it seems like everyone is running away from this request. This is HUGE and can make Syncro so good to use if someone can address this request by so many.
@Andy, I Just got the update and tested it seems excellent.
In regards to the previously mentioned issue:
I can now Click install and then go to another Syncro tab, such as system checks for that asset, and it will now show the “installing” text, which prevents additional attempts to install.
However, if you refresh the “Windows Patches” Page after clicking install, it will revert and then give you the option to install again.
I know it’s minor, but I like consistency, so it would be cool if that could be updated.
It’s not necessarily an inconsistency, because that is just a visual thing we did so people don’t spam the install button. We won’t know in real time if the patch completed or not, particularly if it needs a reboot, so those won’t update until the asset syncs back again. So the “installing” button will never change on that page until after a page refresh and an asset sync. Then you’d either see it switch to the recently installed section, say “install” again if it hasn’t completed, or “pending reboot” if it can’t finish until after the machine has rebooted.
Ok I like the fact that it says “installing” and prevents the additional use of the button.
I just wanted to see the same behaviour if the page is refreshed.
Currently, it will give you the option to press the install button again if you just refresh the page. should it not still show as installing and then go into the failed field to attempt it again?
Installing is effectively a visual representation that you triggered something. We can’t maintain that state because without an asset sync we don’t know the status of what is occurring there in real time. So it might be installed and then it would update on the next asset sync, or it might need a reboot which would reflect on the next asset sync, etc. It would only show up in the failed section if the install actually failed, which would also be reflected on the next asset sync.
Would it be a huge ask to have multiple schedules an a patch profile?
The new patching options are good. However I’d really love to be able to get down to a single profile for workstations.
The new patch profile works awesome for assets that are always on, but for those that are more sporadic I have an overnight reboot window, then later in the monthI have a mid day patch window, then first Tuesday of the month a mid day patch window with a prompt for reboot.
It would be really great to be able to add multiple schedules to a patch rule, or possibly even be able to set patches to install (without reboot) at the earliest opportunity after missing x patch windows or something along those lines.
I can create a property feature request thread if that would be better
What I recommend is you patch workstations on a daily basis and set the patch policy to not reboot for patches (that is what I do). Then, you have a reboot script (or monitor as I do) that you can set custom variables for and reboot the device at a specified time either in your recurring reboot script or setup as a monitor as mentioned.
I have been using the policy to do reboots but your right doing a daily reboot monitor script separate from the patch policy would simplify the patching schedules quite a bit
