Run Script Against Saved Search, but make it Dynamic

I noticed that we can target a saved search when running a script, but this doesn’t appear to be dynamic.

I was trying to find a way to reboot all the assets that have the Pending Reboot field. I looked around and I found that the Pending Reboot field is a property condition under the saved asset search. I can build a saved asset search, then I could run a script to target that Saved Search, however often I wanted it to run, but it doesn’t appear to be dynamic. This means that whatever assets match the very first time the script runs is what will continue to be targeted.

PLEASE EXPAND ON THIS AND MAKE THIS DYNAMIC - If the saved asset searches were dynamically created every time the script ran, it would bring so much power and even more automation to the platform.

In the case of the Pending Reboot, what should happen is that if I target a saved asset search, it should look to see what assets match that search and run against those only. So if I schedule a script to run every night at 9 pm, it would find all the assets that match that criteria, then reboot them. This would clear that field and then the following night, the script would run but it would only find the ones that matched.

The Pending Reboot is just one example. If these were dynamically generated each time a script was targeting a saved search, it would open up so much more automation for us.

5 Likes

Yes the whole saved asset searches are static. They only refresh when you click the link or refresh the page. Even the number next to the search won’t update automatically. Also, if you schedule a recurring script on a group, it’s really doing it per asset, so you can’t even bulk manage it after you set it. Ideally, I would love to see more tabs when you edit a saved asset search and one of those tabs would be scripts, where you can schedule scripts against the search, but that would also require it to be dynamic. There’s so much automation you can do with dynamic groups, Syncro is really missing out on a lot of potential here. This is one area of CWA that I would praise them on for getting right. It validated each group every hour to add/remove agents from the group. I used this a ton to remove software or add software, or audit stuff.

This is something we’ve been looking for as well for quite some time.

Is there any official response from Syncro Dev as to if this is on the roadmap? We were hopefully that the nested policy implementation would have given this to us but because they are client specific and an asset can only belong in one folder it’s not helping this problem much.

As of today we are working on a design that leverages a daily role detection script that instruments the windows task scheduler local to the asset.

They had the opportunity to embrace this kind of dynamic power when they rebuilt the policy system and they chose not to. Andy and others are fully aware of what other rmm’s are capable of and they purposely didn’t go down that path. I’ve heard before that it would be ‘too complicated/complex’ and would lead to people doing things they didn’t expect (and therefore more support tickets for Syncro I’m sure). With great power comes great responsibility, give me the capability. Anyway, for this and other reasons (6 hour syncs, 1 hour ticket automations, report limits, recurring invoice and sync issues at peak times, etc) I can only conclude that Syncro either doesn’t have the technical capacity, or doesn’t have the database robustness, or doesn’t have the money (or a combination thereof) to fund such dynamic and realtime functions so they just avoid them when possible. I don’t foresee this changing anytime soon unless they have some major revamp in the works that allows them to do more with less.

1 Like

This is probably one of my most wanted features. I was actually on the line with a product specialist the other day and I asked him specifically about this and he kinda chuckled and said I must be familiar with Datto RMM. I said yes, that is a product I’m intimately familiar with and having dynamic searches/filters to be able to script against is a game changer.

CWA has dynamic groups and is about the only thing that worked well. I miss the power of dynamic groups, hopefully one day, Syncro will have them.

I’m going to bump this again. @Andy How do we know if feature requests are even being considered?

The more and more I use Syncro, the more I miss this ability. This would open such a wonderful world of being able to target scripts to certain saved searches/filters. Could even expand this and apply Policies based on filters, which would be massively beneficial.

This is like, 1 of my top 3 items I’ve love to see Syncro consider doing. It would also elevate Syncro and give them more flexibility to compete with the larger RMMs imo.

I help another company that already has an RMM and has 27k endpoints (yes, 27,000) lol and they would never be able to use Syncro and this is one if the big reasons why.

1 Like

If it’s in the forum it’s being considered.

I get the use case and would definitely support the feature for larger customers like the one you are describing. This one in particular is a ton of work so I wouldn’t expect this any time soon, particularly when there are other areas of the PSA we need to bring up to speed first. But like most things, the more people that support it the more interesting it becomes.

It’s definitely useful for larger customers, but honestly, it’s massively useful for even the small guy. If we could do filters/groups it would be a game changer.

Let’s say you have a group called “No Patching” and then you have a filter called something like Default Patching - Servers and you set the criteria to whatever you want, and be sure to include where Group doesn’t = No Patching. You can apply a policy to that filter, and it will get all servers that fall into the criteria of that filter, as they are added to your system. You need to exclude a system? No problem, simply tag that one server into the No Patching group, and the policy no longer applies to that server and it stops patching. You could do this with custom monitors, all sorts of things and be super flexible.

It’s just something I think would be crazy awesome to see in Syncro. I do appreciate the response.

Well running the script as a one off will always be accurate. It’s only when you schedule against a Saved Asset Search where that search is static at the time it’s defined.

So if you are talking against running to match policies, you can already do that today. Just add the recurring script to any given policy and have it apply everywhere the policy is applied. That’s the entire idea behind the policy inheritance model.

That’s not what I mean no. I’m fairly confident what I’m looking to do, cannot be done currently in Syncro. Sorry if I wasn’t clear, I kind of mixed 2 ideas together as I see it benefiting multiple areas of Syncro.

  1. I create a saved search for all Windows 10 machines not on 21H2 for example. I then schedule a script to run against that saved search that confirms they are not 21H2, and attempts to update them. Once a machine is updated successfully, they should automatically fall out of that saved search (filter) and when new devices are onboard, if they meet that criteria, they should automatically get included in that saved search and that scheduled script should start running against them. That’s my idea for monitoring. Being able to create filters and exclusion groups where you can schedule scripts against a filter and have it be dynamic. Attaching a script to a policy currently only runs that script when the machine is onboarded and that’s it, or on whatever set time frame Syncro defined.

  2. Patching again, that example would still partially fall into my above example. Right now, as I understand policy inheritance, I have to move devices around and place them into “Workstation” folder or however someone has it organized, and let the devices under it inherit that policy. If I then want to have an additional policy for something else, I can do that down the line in another subfolder or directly to a machine (this is how I do it now when I have specific things that need to be adjusted). This all requires assigning policies directly to a device, to a folder, etc.

In the way I described above, I could theoretically have 2 main patch policies to start off with. Server Policy and Workstation Policy. I create 2 filters, Server Default Patching and Workstation Default Patching. I create a “group” (Syncro doesn’t have this yet either, but I guess this part might be accomplished by doing a custom field and tagging it in someway) but let’s say I can create a group and select machines I want to manually place into that group. So I have a No Patching group. So the 2 filters says something like “OS = Windows Server (Or Windows Workstation)” AND "Device is NOT in Group “No Patching”.

Now I onboard 100 devices. Based on my Server and Workstation Patching filters, those 100 devices automatically get one of the 2 patching policies. I don’t have to set up the customer with specific folders and apply those policies to those folders manually. Now customer calls me and says “Hey, I don’t want these 2 specific servers to patch”. Ok no problem, I throw those 2 devices manually into the No Patching group, and then at some interval Syncro refreshes the policies, sees those 2 devices are part of the No Patching group and so based on the dynamic filters(saved searches) those 2 devices would no longer inherit the patching policy, and would thus stop patching.

As you scale, this because so easy to accomplish changes on group of devices.

If I’m missing some ability in Syncro, I’d love to know that.

What you are describing is dynamic grouping. This is not something we are likely to do, but as I mentioned the vast majority of use cases, particularly use cases revolving around onboarding new clients can always be handled through setup scripts on policies. That’s precisely what they are for.

For example, if you don’t want any machines less than Windows 10 21H2, then this should likely be a setup script on a policy first, and if you really need to check to see if anyone downgraded for some reason after the fact as a scheduled script on a policy secondarily. If you need an inheritance structure for any given customer that should really just be part of your onboarding process. It should take roughly 1-2 minutes tops per customer on top of all the other stuff you’ll already be doing, like entering their contact info, billing terms, etc.

There are other examples where I do get the value of what you are asking, I’m just saying that’s likely a massive amount of work when the bulk of the use cases are solvable another way. Also, as I mentioned you can run scripts against groups of devices based on whatever criteria (adhoc) all day long without issues, you are really talking about running scheduled scripts against them (outside of a policy) which is a bit of a different animal (dynamic grouping).

Yes I am indeed. I have run the adhoc ones. The 21H2 thing might not have been the best example, but I think you get the idea. It’s the ability to turn any script into a monitor and have it run at whatever interval you want, every hour, and have things dynamically enter or exit the group/filter.

I appreciate your quick responses Andy. I love talking shop lol.

Same, always happy to engage at this level.

1 Like

This is exactly what Syncro needs to be more competitive with other vendors. Until you use dynamic groups, you can’t even understand how powerful they are. You gave a good example with Windows Updates. These can also be used for removing bloatware. If 'software" is installed, join group. Group has a script to remove the software. After next sync (we had the sync in our CWA script), software is removed and it leaves the group. This streamlines onboarding. I used this a lot in CWA. When we migrated from Kaseya, I had groups that removed all of Kaseya, KAV, and reset any changes that Kaseya might have done, installed our software, and other onboarding task. I also had groups for removing a bunch of manufacturer apps. Another example that could be used, sometimes our BYO Splashtop doesn’t install and I just have to go and run the script to install it. This could be automated without me ever knowing there was an issue with Syncro pushing it. I really hate needing to run scripts on systems that don’t need them, I think this is a waste of an asset’s resources and Syncro’s resources. With dynamic groups, scripts will only run on machines that match the criteria. There’s also the lack of control if you schedule a script on a group of assets right now. There’s no way to stop it for the group, you have to go in individually and cancel it.

3 Likes

100%. I could talk about the benefits of this for hours, but it seems like this is never going to happen based on the replies.

As I mentioned in one of my comments, the site that I consult for that has a different RMM platform and 27k endpoints, I handle their RMM. The ability to create filters and dynamic groups in insanely powerful. It’s literally used for just about every single automation item I’ve built.

From making sure the proper tools are deployed, to generating alerts for custom monitors, to controlling patching.

This is definitely needed. I think even “easier” would be to add missing software, missing service, missing folder as “checks” in the Policies Monitors area. This can be triggered the same way that the software installed/uninstalled are triggered. If a machine updates it’s inventory, run through the missing stuff list (software, services, folder, file). Doesn’t have to be as high strung as the services check.

Whether you’re big/small doesn’t matter. If i pushed a script out to install something, and something goes wrong, or it gets uninstalled, I’d like to know something is there watching our back. Yes, we can create a scheduled script, to run every 3-4 hours and scan for missing software, but those calls can be a bit “intense” on system resource usage, and would prefer to rely on the existing platform to accomplish this.

Imagine a world where instead of

where onboarding was as simple as assigning the appropriate contract and EVERYTHING else flowed from there. When I assign a contract that includes windows patching it should have patching schedules and approvals and everything for that contract auto assigned to all of the assets with the correct reboot schedules per dynamic group membership etc.

Syncro has a unique place having an integrated RMM/PSA, that really needs to be capitalized on.

I’m honestly a little…I guess shocked that something that seems far more useful and opens up a world of flexibility for Syncro is deemed less important than being able to arrange the nav bar per user or other smaller things like that. It seems there are plenty of people on this forum and probably a heck of a lot more who aren’t part of this community, that would benefit from such a change and would love to have it, yet the attitude seems to be that this is too big of an undertaking to ever be considered. It saddens me a bit because I honestly love a lot of things about Syncro, and I have plenty of experience with other RMMs.

Because contracts vary so wildly from MSP to MSP, normally you’d just have your asset policies handling these types of things. This is particularly true because often times you’ll have exceptions you need to handle within any given contract, particularly for AYCE variants.