It has been some time since I have looked into this as our company moved on from Datto RMM, so my recollection is a little fuzzy. Also I'm retired now, so some of this is slipping away into the ether.
That said, I created a component that would query the target computer for its computer name from the %COMPUTERNAME% environment variable. From this, I creates a screenconnect path and stuffed that into one of the Datto RMM user defined fields. That latter step is done by pushing a registry value, and the technique is documented in the Datto RMM online docs. This component was run on each computer as part of our onboarding process automation.
As for constructing the URL, just mimic the path that you see in ScreenConnect when you click on a target client. It will show something like the path (https://myscreenconnect.com/Host#Access/ALL//aa3103ac-1d11-4cec-aeb2-21dd5621f9c5), based on the grouping structure you use in your ScreenConnect. The long string at the tail end is the ScreenConnect Session ID which is unique for each target computer, but you don't need that. You substitute that with the name of the computer.
This user defined field then is populated with the ScreenConnect link, so if you double-click it, it will open ScreenConnect focused on the target computer.
In a similar vein you can create utilities to launch ScreenConnect in various ways. For example, here is a vbs script to launch based on the clipboard contents. For example, suppose you have a ticket for the client that identifies the computer name. You can grab the name into the clipboard and then run this script. That sequence could be automated into a keyboard hotkey:
Dim wshshellSet objHTML = CreateObject("htmlfile")ClipboardText = objHTML.ParentWindow.ClipboardData.GetData("text")Set wshshell = WScript.CreateObject("WScript.Shell")wshshell.run """C:\Program Files (x86)\Mozilla Firefox\firefox.exe"" https://...." & ClipboardText ,1,FalseSet wshshell = Nothingwscript.Quit
Of course you will need to substitute the actual url path (minus the computer name) for (https://....).
Hope this helps.
Seriously, how hard can this be? Reading through this thread, apparently this is a request that has been ongoing since 2010, which is 10 years ago.
Here is your algorithm:
1. Add an admin-accessible field to the Roles record called max_open_sessions.
2. When a user attempts to open a session, check that user's Role's current open session count against max_open_sessions, and decline to open if the count is greater than that number.
It requires keeping track of the current number of open sessions for each Role, which again can't be too hard to do.
Does this really need an extensive re-design, or a complex extension, that is so hard that a decade is not enough time to get it done?
Given that this was first requested four years ago and roadmapped a year ago, it seems it is not high priority for anyone at ConnectWise. Perhaps this will help: if you actually implement this I will buy more licenses. I have been refusing to buy more licenses until I can control usage, e.g., x number of licenses are available to user type A, y number are available to user type B, and all are available to user type C. Further, by constraining access for certain user groups, this will encourage those group leaders to purchase additional seats as well.
So, please get this feature off the schneid so we can send you some more money!
Rather than using Explorer++ in Backstage, I recommend using Just Manager. It's fully featured, efficient, and I have yet to run in to a bug. It also doesn't flicker in Backstage as some apps do.
I tried posting a link but the post went into moderation, and based on past experience I think it will never exit moderation, so instead google "Just Manager" and it will be the first hit.
Darren: You make a good point about being able to paste commands on the fly and to have a less cramped terminal window with which to operate.
You can put the command script into a file and put it in the toolbox, and then run it from Backstage. This make sense if it is a script that will be used repeatedly and/or on multiple computers at different times, but using the Command tab to paste the commands is quicker for one-off situations.
In summary I would say Backstage overlaps this feature request. In many ways it goes further, while in other ways it does not fulfill it.
Yes and no.
Backstage mode is a truly awesome innovation and is much appreciated. It certainly provides a practical means for running commands on a given device (and much more) without locking up access to the remote machine until command completion or timeout. We use it daily.
What it does not do is provide a mechanism for running a command across a group of machines. Let's say I have a command sequence that I want to run on 500 machines. I can select those machines and run the command(s) against the group, but each machine will be subject to the present limitations of the Commands tab. Further there is no way to capture the output for later analysis.
Of course, that is exactly what I do. But for example if I go to Backstage 10 times a day and virtually every time I want my file manager, that's at least 10 clicks I can eliminate. Every time I jump into Backstage on a server, I pretty much always want to see Active Directory and Group Policy Manager. There are many such examples of common sequences. Multiply this times our entire staff and the efficiency improvement adds up.
Look at it this way. The same argument could be made for launching CMD and Powershell with Backstage. Somebody on the SC team made the decision to do that although that could have been left as subsequent steps for us to do. Truthfully I use my file manager more often than I do Powershell. Why not let me decide which tools from my toolbox to auto-launch?
Hope that makes sense.
Excellent, that works and is almost exactly the solution I was suggesting.
For the reference of future readers, the forum thread linked above was not that useful, but this blog post described the feature:
To test, I did the following:
Worked like a charm. Thanks for the tip.
ps. Anyone interested in JustManager as a Backstage-compatible file explorer can find it here: http://justmanager.ru/. You will want the portable version.
Excellent tips, Max and Jerry. Thank you.
Now if there was a way to make that the default on all of our hundreds of machines without having to set them each one at a time...
UPDATE: The following registry setting can be used from the Toolbox in Backstage (or from command prompt) to set the default console buffer size for the system user to 1000 lines by 150 width:
reg add HKCU\Console /v ScreenBufferSize /t REG_DWORD /d 0x03e80096 /f
Presumably the command could be pushed out to a group of machines at once, though I haven't tested that yet.
Hopefully the next release of the product will allow setting that in the config settings, so pushing is not necessary.
Just wanted to report that after several days of use I'm finding Backstage an extremely powerful new feature. Thanks to the team for doing it.
It has some limitations / issues that hopefully will be addressed, including: the command windows cannot be resized; they do not support scrolling back (so previous output is lost after the small window fills up); there is no cursor indicating text position which makes it pretty tough to edit a command line; there is occasionally odd behavior with command windows not responding, or if you open a new command window it might be all black with no text, etc. Would be nice to be able to add entries to the Toolbox that issue pre-canned command lines to whichever window is in focus, such as oft-used powershell command lines.
Quibbles aside, it's a great enhancement and much appreciated.
Customer support service by UserEcho