Virtual Screen driver similar to that used by MSTSC to eliminate screen resolution limits
Older graphics cards restrict screen resolution. This is not a problem with the Microsoft Terminal Services client which uses a virtual driver and can display much higher resolutions.
Available in Version:
Customer support service by UserEcho
As more and more computers are coming out without a VGA port and only have Display Ports or HDMI ports, this is becoming a fairly big issue and really needs to be addressed as these computers cannot be run headless. Using RDP to access them defeats the whole purpose of ScreenConnect and the additional functionality ScreenConnect provides over RDP.
This also would resolve issues with specific display drivers re: Matrox.
Please, for the love of god do this. It's always disappointing to have these issues and think back to how good life was when I was using LogMeIn with its mirror driver.
Yes. Please. it is terrible to watch the screen move at turtle pace, one keystroke at a time. Please revert to mirror drivers instead of Direct to Video card . Only option is switch to basic VGA mode on server. What is the point in that. LOGMEIN, TEAMVIEWER, no problems. CONNECTWISE could lose clients if they do not move to this feature asap
This is a very big issue for us as well. We manage a lot of servers and the physical ones are almost unusable due to the lag. We are finding ourselves ScreenConnecting into another server and then RDPing into the one we have to work on so it is usable. The guys also complain about the Screensize and why we can't do fullscreen like they can in RDP.
This also does not work to access the console with on Windows Server instances in Google Compute Engine. Major problem; please prioritize fixing. If I RDP in and then join and switch to that session, it works, but there's no independent/external method of getting onto the server unless there's an already-joined RDP session, so that makes ScreenConnect/CW Control utterly worthless to use on a GCE Windows Server instance. :(
Yes, this is an aspect we get complaints on - as most users are remoting in on laptops with much smaller screens. It requires constantly zooming in and out. Please develop this asap!
As well as being able to run dual monitor on a remote system that has one monitor
Are any of your free to jump on a call to discuss this request in more detail? If you are, please use the link below to schedule a time that works for you.
It seems the resolution issue is increasing on new Windows 2016 and Windows 10 headless nodes. Really hard to work on 640x480 screen.
We also have this issue with connecting to AWS Instance's. With RDP we can easily connect to a remote server with no physical monitor and tell MSTSC to virtualize across all three 2k Displays at a techs workstation but with ScreenConnect (Control) we have no way of doing this....
WE simply can not use this product if the laptop lid is closed.
I second this - in addition to the resolution I'm told the mirror driver is much faster as well, similar to TV or RDP. Slow connections are painful currently.
Yes, please develop this. A real pain to jump through 2 hoops to get useful resolution, instead of 1. This should have fixed as soon as it was spotted.
We just signed up for the service and paid for a full year of service, now I am wondering what kind of huge mistake that I just made. We have many servers in a rack headless at a data center, this is a disaster. Please fix it.
Had Control for a day and I this is a big issue for us...
Are we any closer to this? I want to provide remote login via "control" and I have to set up real displays on those remote devices. Especially if I want more than 1 display. Why not just let me create a virtual display for screenconnect?
Adding my voice to this. It's understood that this is a remote support tool and thus the flexibility to remotely support nearly anything is a must.
That said, we have only seen this be a problem with discrete GPU's with Displayport right now. Most of the machines we support are onboard DP and do not have this problem.
Can't we just send a trigger to the OS / GPU to activate output? There must be a better solution than RDP or dummy plugs.....
For a tool that is supposed to provide remote access, it is crazy that the function doesn't even work properly all because a laptop might be closed.
While working to solve this please have a look at another RDP feature request:
We've had issues with vendor provided drivers since 2019.2/2019.3. In our support conversations it's been indicated that this would mitigate/resolve this issue. Hopefully we can get more than "under review" soon.
Every other remote control tool seems to work to connect to headless but Screenconnect. I've used Teamviewer, LMI, Takecontrol, and even ANYDESK and they all work...why in the hell can Control not figure it out?
My single biggest complaint with SC is working with headless machine. Every other remote desktop software I have used handle this. With Control, I'm I suffer with low resolution on headless machines. Even worse, I now have 45 new Lenovo M715Q Tiny PCs to set up and they will not work with Control at all unless a monitor, kb, and mouse are connected. And yes, I've been through the "blank screen troubleshooting". This is such a glaring product deficiency. Please fix it!
When will this issue be addressed. This becoming a big problem. I pay good money to use this remote tool and not being able to connect to a new AMD laptop with the lid closed or a headless desktop is a big issue.
Lets get this done. I'm away from my office for 30 days and stuck at 800 x 600. I can't even believe this.
A simple workaround until they can build a driver is for them build a function so we can RDP over the control connection.
Give us a rightclick and RDP button. This would allow users to set the resolution to what ever they want and would fix many other issues that same time.
Did you test the bridge extension already?
The bridge would probably work great for Control only users. Our staff uses Automate via the control plugin and because we have all our access permissions built in Automate the bridge won't work for us without a huge overhaul of the Control / Automate integration.
Then when users are in Automate they could select RDP that would tunnel over the control session. Making more users happy with one change. Then as control matures, they could implement some driver to adjust screen resolution.
At the moment this request was over 4 years ago and they don't seem very interested in building a driver to adjust the screen resolution. Maybe this would be a happy middle ground until it gets built.
Just my 2¢.
With recent events - this thing has become more of an issue - to a point where we are looking for alternatives. I could never get the bridge service to run our account. I've installed and reinstalled it multiple times and I still can't enable it. It'll be really nice to just add RDP mode ala Backstage.
I assume everyone knows about the headless dongles. We use them for adding a second monitor for remote users. There are HDMI and DP styles. Yes, they should fix this, but until they do, the dongles are cheap.
We started using those but stopped on our 50th box. We have a lot of headless nodes.
Come one CW let's get this done
Still hoping this issue gets resolved. It has been years already. Also, has anyone of you heard about Gacha Life? I'm an anime lover and I heard that this game is a must try. From what I gathered, you can choose a character and customize it depending on your preference. After that, you're free to explore its anime-like world. I'm excited to try it and maybe invite some friends to play it with me on PC: https://chrome.google.com/webstore/detail/gacha-life/bidldpedmamenefcipmhojmhjohmblnl
Very anxious to see this rolled out. Currently still having to use Microsoft RDP connections that allow for higher resolutions since 800x600 resolution is not doable for most remote server-work; would much prefer using ConnectWise ScreenConnect once this is implemented.
Customer: Is it fixed yet?
Support: .... Um.. Right after i find a way to change your screen resolution.
Customer: It looks fine on my end. It works with our remote control software perfectly fine.
Support: Can we do a remote session into your computer and then back into the server? I sure hope this doesn't go down at night.. No way we could fix this system.
It's been 5 years come on.
I have yet to come across another remote access tool that cannot connect to headless systems... this is happening more and more with the work force going remote. Now that CW has acquired Continuum, and with the recent decision to kill the LMI interface/tool in July, the timer is ticking... ConnectWise, YOU NEED TO GET A MIRROR DRIVER IMPLEMENTED BEFORE KILLING LMI! We need to be able to connect to headless
6 years and going strong. Such a simple request, must be an insane amount of work to implement?
Any update on this Connectwise?
well, at long last, I found a solution to this ongoing problem. PAY ATTENTION CONNECTWISE!
link here: https://www.amyuni.com/forum/viewtopic.php?t=3030
but since I am sure this will be the workaround for another 6+ years, and that link will probably die, here are the details:
Amyuni has a virtual usb display driver, available here: https://www.amyuni.com/downloads/usbmmidd_v2.zip
unzip that file, open an admin command prompt, go to the folder where you unzipped it all and run:
now you can select a resolution other than 640x480, because there is a virtual monitor that screenconnect can see.
EDIT: I've found that this doesnt survive a reboot, but is repeatable, so at worst it could be scripted upon startup. I am sure someone else will find a better way to invoke this on demand.
(if that usbmmiidd_v2.zip link dies, search for virtual display drivers. if that doesnt work, message me and i'll post it somewhere accessible)
I can confirm that this works a treat. A toolbox executable to automatically run it would be great as it's a tad time consuming setting up via backstage.
Brilliant work asherman34 - that saved me a load of time :-)
I had the issue where my remote system was on a HDMI switch and I could not perform a remote control session, I could connect but see nothing. When the switch was switched to the remote machine the display would activate, still not allowing control but showing any screen changes!
This solution worked.