1 vote
It’s still not the best. Serious issues:
1) Linux "Execute macro/script in the terminal": Compare your solution with two others on the market: SuperPutty and MobaXTerm. If you improve this, you will certainly significantly increase the number of users who migrate to RDM.
2) Devolutions Agent (script execution): Relying on an Agent to execute scripts—and for other "benefits"—is extremely poor. Looking at tools like Ansible and many others that do NOT require a client, this is an approach worth pursuing. If you improve this, you will certainly significantly increase the number of users who migrate to RDM.
I hope you recognize the importance of these requests for users who rely on RDM as an infrastructure support tool. Good luck, and keep us posted.
In Attettion,
Hello,
Thank you for your feedback. I'll answer both of your points.
Executing macros/scripts in the terminal
We'd like to improve this, and I suspect part of the problem is how the feature works day to day, not that it's missing something per se. In case you haven't run into them yet, RDM already has a few related features:
If you already know these and they still don't measure up to SuperPutty or MobaXterm, I'd really like to understand where they fall short. Is it the amount of clicks to reach the feature? The ease of finding these features from the start? It would be very helpful to know exactly how you do what you do in these other applications, and what the points of friction are in RDM.
Running scripts without the Devolutions Agent
I don’t think comparing Ansible with the Devolutions Agent is quite fair, since they’re different tools. Ansible lives on a dedicated server whose whole job is to connect to your machines over SSH or WinRM, deploy the script, run it, clean up and report the results. The Devolutions Agent is a persistent process on the remote machine itself which a client like RDM can leverage. In both cases something is always running to do the work.
If we’re only talking about the mechanism, running a script without an agent, then yes, RDM could do the same thing as Ansible: connect over SSH or WinRM, run the script and clean up afterwards. Most of the pieces for that already exist in RDM. It would still be a big feature, though, because it’s not fire-and-forget. With no dedicated server or agent doing the work, RDM itself would have to drive the whole process and stay tied up until the script finishes. We’re not sure yet that a client application on its own is the right place to control that kind of work, and there would be a lot of edge cases to sort out.
So I do understand the need, and it’s not something we’re ruling out. It’s just not as simple as it looks, and we will keep an eye out for additional feedback to help us prioritize this
Regards,
Hubert Mireault
Hello Hubert Mireault,
Thank you for your valuable feedback—it is much appreciated.
i) Regarding the first point, "Executing macros/scripts in the terminal":
Wow! I was very impressed by the implementation you showed me. The "Broadcast All" feature for commands across multiple SSH sessions is exactly what I needed—it’s a real productivity boost for RDM and deserves more visibility.
I suggest continuing to highlight features like this—perhaps via a dedicated panel, using simple examples, screenshots, or short videos—so that RDM users become aware not only of new additions but also of significant, high-impact features such as this one.
ii) Regarding the second point, "Executing scripts without an agent":
You are right to point out that these are different tools and that a direct comparison might not be fair. Please accept my apologies; I don’t think I explained myself clearly.
In short, my suggestion was that, since RDM establishes Windows connections using port 3389, this same port could be leveraged to eliminate the need for a separate client or agent. Installing an agent across a massive fleet of machines—especially those protected by multiple firewalls—is simply not feasible.
A practical implementation of my suggestion would be to execute commands in the same way you demonstrated for SSH sessions (using "Broadcast All"), but applied to DOS, PowerShell, or the Windows terminal within an RDM RDS session. This would truly be a significant productivity advantage for RDM.
Hubert Mireault, thank you very much—I hope to speak with you again soon!
[ ]sss