Yea I totally understand from both view points. There are a lot of house up keeping they can improve on over time for sure:) Hopefully after this release, this should give them time to start working on some of the feature request we have to further advance our needs. I am just saying from a GUI to Code out put - it would just be a bit faster to script it your self for now than to wait for the GUI to play catch up. Only because everyone’s needs are going to be different than someone elses. Thus it would just be easier to script it out than to wait for them to create an all purpose design.
As for scripting everything - that is kind of the power of the RMM tool though. At least we are not lock down waiting either. Everything else we can just script out when needed and move on. In a way I wish they gave us more options to allow for more command like search options as well.
Quite honestly, even if they had this built in, I would still end up with the same solution I created and use currently, because it offers much more flexibility than any cookie cutter solution is going to offer. Unless you want to create and maintain numerous different update policies per site, per device, etc., it seems much easier to just script in such a way as I mentioned previously.
I’ll venture to say that is why some of us probably don’t feel it’s a big deal to have this.
In a more simply deployment, then absolutely I can understand why this feature would be wanted. Just set it via the UI and forget it. I get it. Maybe they will add it eventually.
Hmmm I wonder if it would be worth for them just to add a scripting option there instead? This way it still places it into the same place - but gives you the flexibility we are use to using?
This holds true for any RMM that has scripting capabilities though, it’s not unique to Syncro. As long as a platform is stable and has a scripting engine, you can tweak it to do mostly what you want. I have scripted a lot of stuff that could easily be built into the agent and be a part of the syncs. Truthfully, the agent doesn’t audit enough info, or it only exist in Background Tools and is not cached. Idle Time, Storage (Volume info is not cached), Mapped Drives, User Accounts, Attached Screens, Installed Printers, Local Admins, and Bitlocker status are a few of the things that I’ve had to script that could be part of the audit. I know I don’t have as many scripts running against agents as some, but at one point is it too much? Running scripts aren’t free resources for either Syncro nor the asset.
Now this point I completely agree with. There is definitely information that at the very least should be optional to include in the sync schedules. And on that note, more info needs to sync, faster/more frequently.
I do understand that the more frequent syncs = much more load on the backend, so I get all that has to be upgraded to be able to handle it, it’s not just development time in code.
If you have it in the agent or scripting - it still all requires time and cpu cycles. This is why they limit some scans for 6hr+ or more. Yet, depending on the request, somethings are faster done over time vs all at once. So in lots of ways scripting out your needs is better than trying to have the agent do everything at once. I know they said they are looking into splitting up some of the task into more controllable functions / syncs later in the future.
On the flip side, not everyone needs all that information as well. Trying to predict and allow it into GUI is much harder to code for than just allowing you to create your own variables and fill them in as you need instead. This way its way more flexible and gives you the options as you need as the operator.
I am not against having the agent get this stuff on its own or built in. Just saying everyone needs are going to be different over someone’s else and programming all that out in a GUI is going to be harder said than done sometimes.
I cannot believe you all. This is a major improvement over what we had with features that are amazing and it is all unexpected. I guess this is proof you cannot make everyone happy. This group seems to be full of people that find fault in everything and anything. Seriously if you do not like it do not use it. turn it off and do your rinky dinky scripting. or whatever it is you think is better. but for the rest of us, we are happy with these enhancements and improvements because it makes the product better. We knew what it did and did not do when we signed up and it is now better than before we are happy and pleased with the hard work the Syncro developers have done and we will always welcome these free updates for what we see as one of the best tools we have and use.
You misunderstand, I’m happy with these changes, but a little more effort with tweaking the reboot options while they were visiting and redesigning and it could have been even better. Reboot options have been an issue for as long as I’ve been involved with Syncro. It’s been complained about frequently with it being confusing, end-users confused and accidently restarting their system, or just the lack of control on what to do when patching is done. Andy has said repeatedly that when a feature is visited and worked on, it is more likely that related parts can be improved at that time, so I feel this was a miss. Improving the core is great and will please the masses, but knocking out some of the long standing headaches at the same time would make a lot of sense.
Well now we are talking about two different things. If the asset is offline and you have it set to run a missed schedule as soon as it comes back online, then yes, there could be a scenario where the reboot occurs midday.
If your assets are offline consistently this is going to cause other downstream effects. For example, if you had a reboot scheduled for a specific time (which would likely coincide with a scheduled patch cycle anyway), the asset in question would be offline in both instances. So now as a result future patches couldn’t be installed until the existing patches finished processing after a reboot.
Let’s say the user leaves their system on for the week, but for some reason, shuts it down on Friday. It won’t get the patches that are pushed on Sunday. So Monday morning, after the delay, it starts patching, then ideally, the system would reboot late Monday evening, or early Tuesday morning to complete patches, without involving the user. With a reboot window, if the system is on, it will only reboot during the window, if not, it will wait until the next reboot window and try again. Syncro does not expose the reboot pending flag, so if we want to reboot only machines pending reboots, the script has to validate against a minimum of 3 registry keys, it’s more complicated than is needed. It’s great that you guys have daytime patching (without calling it that), but the current reboot options do not take this into account, so it’s either don’t use the reboot options, or don’t allow daytime patching.
If you have the setting to process the patching schedule when it was offline, then yes, this is accurate. Otherwise, they’d get processed (and reboot accordingly) after the next schedule runs. Once OS patching is fully out the door we can look at reboot improvements. This one hasn’t come up a lot, but it’s a valid use case.
Hello, we currently use the windows upgrade assistant, i have the basic commands below which can be pushed out as a powershell script to download and run the upgrade.
@Andy I just got it today as well. I’ve already adjusted my policies to incorporate the changes. Layout was exactly as the video showed and super easy. I’ll be keeping a close eye on it tomorrow as my workstations patch daily but I now have the defer times setup so I’ll be curious to see the changes in action!
But when this update hit my instance of syncro this morning - despite having settings set not to reboot servers and workstations…we got flooded with tickets that our agent was updating and rebooting machines…
This isn’t the first time this has happened either - I had at least 5-6 servers this morning reboot during production - this was set to NOT reboot anything even before this change.
