Skip to main content

Remote Desktop on High DPI screens

Scott Hanselman wrote a nice blog post back in January about some of the issues you might face running Windows on a High DPI screen like that of a Surface Pro or Lenova Yoga. I'm kindof mystified that he didn't mention Remote Desktop though because thats been the number one problem for me on High DPI screens.

That said, if you remote into very recent Server OS's like Windows Server 2012 R2, then apparently Remote Desktop will sort out the DPI scaling automatically. Perhaps Scott hadn't noticed the Remote Desktop issue because he only remotes into Server 2012 R2. Certainly if I was Scott, I wouldn't remote into anything less than that.

But, in practice, I regularly have to remote into Server 2008 machines and yes even Server 2003. If you do that from a high DPI screen, the remote desktop is rendered at regular pixel size, which makes everything tiny.

Its hard to show screenshots of High DPI screens that correctly convey the pixel size, so I've photoshopped them onto a picture of a Surface and its pen, to give you an idea of scale:


Suffice to say, its hard to get anything done when everything is that size. There are an annoying number of not-quite-right solutions to this that don't work:
  • The Windows RDP client has 'Smart Scaling' - that will let you scale a desktop down to display a large amount of desktop in a smaller box ... but it won't let you scale up to display a smaller-res desktop in a larger box.
  • The Metro RDP client has a Zoom feature - but it won't let to set the screen resolution of the remote machine (so you can't, for example, connect at 1280x800 and scale up)
Turns out the solution is to install an alternative RDP client with a similar sounding name of Remote Desktop Connection Manager 2.2

This is a souped-up version of the Windows RDP client, apparently intended for people switching between many different servers. It displays a tree of servers on a panel to the left of the screen, and displays the remote machines desktop on the rest of the screen. With the right settings, you can get it to display a sane sized desktop on a high DPI screen:


As you can see, the remote machine now appears within the Remote Desktop Connection Manager client area, but it is rendered at a much more usable scale.

To get it to display correctly, I needed to set the 'Remote Desktop Settings' after adding a new server, and select the 'Same as client area' option:



Thanks to Falafel Software's blog post for pointing me in the direction of this solution.

Edit (July 2015): This is a Windows 8 solution, it wont work on Windows 7. Also, there is now a newer version of Remote Desktop Connection Manager (2.7) that doesn't fix scaling as described here. So you need to get the 2.2 version (linked above) in order for this to work.

Comments

Dave said…
I'm definitely going to give this a try. This might actually save my eyes.
Thanks.
Max said…
This doesn't work (using Windows 7), using a Dell 24" 3840x2160 display. There is no scaling at all.
Ian said…
Hi Max, did you try selecting 'Same as client area' option in the settings (in screenshot above?). It works for me, perhaps its a Windows 8 only thing.
Max said…
Hi Ian, thanks for your response!

Yes, I tried that 'Same as client area' setting. Also, my Text size settings is set to 125%.

Oh well! If I upgrade to Windows 8.1 I will try again!
Buck said…
This fixed the scaling issue, but when in fullscreen how do you access the onscreen handwriting pane?
Anonymous said…
I have been having nightmare for this problem. And installing remote desktop connection manager really helps. Thank you so much.
Anonymous said…
My remote desktop requires a smart card for authentication. Is there a way to get Remote Desktop Control Manager 2.2 to use a smart card?
David.P said…
Hi,

also here, this doesn't work (using Windows 7). There is no scaling at all.

Is there any trick to it?
Ian said…
David.P - This only works for Windows 8 I'm afraid, wont work for Windows 7.
Anonymous said…
Royal TS works much better, I can scale full screen remotely at 1920x1080 from my laptop with 3840x2160

www.royalapplications.com/.../download
Anonymous said…
Version 2.7 still works too, it just disables the DPI scaling by default, but it still is an option. If you browse to the location of RDCMan.exe. (C:\Program Files (x86)\Microsoft\Remote Desktop Connection Manager) by default. Right click RDCMan.exe select properties, select Compatibility tab and uncheck "Disable display scaling on high DPI settings".
Anonymous said…
-- Version 2.7 still works too, it just disables the DPI scaling by default, but it still is an option. If you browse to the location of RDCMan.exe. (C:\Program Files (x86)\Microsoft\Remote Desktop Connection Manager) by default. Right click RDCMan.exe select properties, select Compatibility tab and uncheck "Disable display scaling on high DPI settings". --

yeah sweet thanks. (it does not seem to be able to enlarge remote desktop when enlarging window, but this can be easily fixed by starting remote desktop connection in maxed window - then it all works perfectly)
Anonymous said…
Same problem here with Server 2012 and Surface 4. M$ RDP picked the resolution of the surface. I cant see anything. The best solution was to install Royal TS. I even have since version 1.8 a licensed version. Best software for RDP connections managing.

Totally recommed this! http://www.royalapplications.com/ts/win/features

Anonymous said…
It does work with 2.7, see this link:

http://superuser.com/questions/891413/remote-connection-desktop-manager-2-7-does-not-support-dpi-scaling-anymore
Amit Misra said…
Have you tried using R-HUB remote support servers http://www.rhubcom.com/v5/remote-Support.html on Windows high DPI screens? If not, then I would recommend try it out. It works well.

Popular posts from this blog

SSRS multi-value parameters with less fail

SSRS supports multi-value parameters, which is nice, but there are a few issues with them. This is how I deal with them. Two of the problems with SSRS multi-value parameters are: You have to jump through a few hoops to get them to work with stored procedures The (Select All) option, as shown above The reason the (Select All) option is a problem is that it is a really inelegant way of saying 'this parameter does not matter to me'. If you have a list with hundreds of values, passing all of them as a default option just seems wrong. Also, if your report shows the user which items they selected, printing the whole list when they choose (Select All) is excessive. So in this post I'm going to show my particular way of: Jumping through the hoops to get Multi-Value params in a stored procedure Adding a single '--All--' value that the report interprets as meaning all the options. Getting Multi-Value params to work with Stored Procedures This is

Copying data to Salesforce Sandboxes using TalenD

A common problem with Salesforce Developer Sandboxes is that they are blank. Really you're going to want some data in there, so there are various strategies for copying data from your live instance to the Sandbox. There are some paid-for solutions - SFXOrgData , Salesforce Partial Data Sandboxes - but if you've got a decent ETL tool you can build your own. There are a bunch of free ETL tools for Salesforce: JitterBit Data Loader is good for quick ad-hoc tasks but the free version makes it difficult to manage specific ETL projects or share projects with other users Pentaho Community Edition - an open source edition of the enterprise version Apatar was a free open source Salesforce ETL which still works but development seems to have stopped since 2011 TalenD Open Studio is an open source ETL tool For the task of copying data from live to a Sandbox, either Pentaho or TalenD Open Studio could be used, depending on preference. Here's a good comparison of the dif

Bug Hunter in Space

In 1987, Acorn launched the Archimedes home computer. At the time, it was the fastest desktop computer in the world, and at the time, I was fortunate enough to have one to experiment with. The Archimedes was great, but it never really took off commercially. However, it was built around the ARM processor, which Acorn had designed itself when it could not find any existing processors suitable for its 32-bit ambitions. The ARM processor was a masterpiece of simple and intuitive design, and its still around today, with most of the instruction set pretty much unchanged. In fact, you've probably got one in your pocket right now. Its design makes it process very efficiently on low energy intake, and hence it is estimated that about 98% of all mobile phones contain an ARM chip. Over 10 billion ARM chips have been shipped, and they outnumber Intel's long running x86 series of chips by a factor of about 5 to 10. I had learned programming on the BBC Model B , and when we got the A