none
Change DPI scaling inside RDP session (2008 R2 / 2012 R2) RRS feed

  • Question

  • We have two servers:

    • Server 2012 R2 RDS 
    • Server 2008 R2 RDS

    Users are constantly reporting being unable to change their screen resolution. After some digging, the reason they're trying to change the resolution is because their text is too small to see. DPI scaling is obviously the answer, but when users go into the setting it is greyed out and cannot be changed.

    Now, for Server 2008 R2, I've found this link:
    http://support.microsoft.com/kb/2726399/en-us

    Does this hotfix actually do what I suspect/hope/blindly-pray it will do? Does it re-enable the DPI options if connected via RDP? The article doesn't actually say what it does, just that it will "fix" the issue.

    Next, for Server 2012 R2, I've found this link:
    http://blogs.msdn.com/b/rds/archive/2012/06/13/remote-desktop-services-what-s-new-in-windows-server-2012-release-candidate.aspx

    The second last section mentions "Support for Changing DPI in Remote Sessoins." Having logged into this RDS server, this is not the case, the setting is greyed out just like in Server 2008 R2.

    1. What needs to be done to get this working on both platforms? My end result is I want users to log in and be able to go into the preferences, move the DPI slider to their desired text size and fix their problem without resorting to workarounds like decreasing the resolution of their local PC to increase the apparent size of text.
    2. If this isn't possible, is there a way to configure RDS to run at a lower resolution permanently but to stretch to fit any screen resolution? Right now, if you drop the resolution on an RDP session, it just takes up part of the user's screen. In the newest RDP clients, I notice the Smart Sizing option, but it apparently isn't "smart" enough to stretch higher than the base resolution of the session.

    I've looked through literally years of forum posts and articles and nothing seems to point at a user-friendly fix such as take the slider, choose your size, done.

    Wednesday, February 5, 2014 7:12 PM

Answers

  • Hi,

    For Server 2008 R2 you need to apply the hotfix to allow users to change the dpi within their session, and they will need to log their remote session off and back on for the change to take effect.

    For Server 2012 R2 the behavior depends on the client.  For Windows 8.1 clients manually changing the dpi within the session will be disabled because the session will automatically use the dpi setting from the client.  For example, if the local Windows 8.1 PC is set to 125%, then their remote session will be 125% as well.  When you make a dpi change on the local PC it is best to make sure you start a fresh remote session (instead of just re-connecting to an existing session) so that any applications that do not handle dynamic dpi changes can adjust.

    For other clients, they may change the dpi within their session and then sign out of their remote session and then back on for the change to take effect.

    -TP

    Wednesday, February 26, 2014 7:14 PM
    Moderator

All replies

  • Hi,

    For Windows Server 2008 R2, you may need to apply the Hotfix in your post.

    The DPI adjustment is not available in a Remote Session (RDP)

    http://support.microsoft.com/kb/2544872

    You cannot change the DPI setting through a Remote Desktop session on a computer that is running Windows 7 or Windows Server 2008 R2

    http://support.microsoft.com/kb/2726399/en-us

    However, when I remote to a Windows 8, Windows Server 2012 and Windows Server 2012 R2 machine, I have no such issue.

    Please check if your clients have the latest update for RDP installed.

    Resolution and Scaling Level Updates in RDP 8.1

    http://blogs.msdn.com/b/rds/archive/2013/12/16/resolution-and-scaling-level-updates-in-rdp-8-1.aspx

    Description of the Remote Desktop Protocol 8.0 update for Windows 7 SP1 and Windows Server 2008 R2 SP1

    http://support.microsoft.com/kb/2592687

    Remote Desktop Protocol 8.1 Update for Windows 7 SP1 released to web

    http://blogs.msdn.com/b/rds/archive/2013/11/12/remote-desktop-protocol-8-1-update-for-windows-7-sp1-released-to-web.aspx

    Hope this helps.


    Jeremy Wu

    TechNet Community Support

    Friday, February 7, 2014 9:41 AM
    Moderator
  • It is possible that my clients on the network don't have the newest version yet, but I'm testing from my PC which is running Windows 8.1.

    MSTSC is showing this for versions:

    The options is greyed out on Windows Server 2012 R2 RDS session host:

    Friday, February 7, 2014 2:31 PM
  • Add feature Desktop Experience.
    Friday, February 21, 2014 9:55 PM
  • Already set up.

    Wednesday, February 26, 2014 4:01 PM
  • Hi,

    For Server 2008 R2 you need to apply the hotfix to allow users to change the dpi within their session, and they will need to log their remote session off and back on for the change to take effect.

    For Server 2012 R2 the behavior depends on the client.  For Windows 8.1 clients manually changing the dpi within the session will be disabled because the session will automatically use the dpi setting from the client.  For example, if the local Windows 8.1 PC is set to 125%, then their remote session will be 125% as well.  When you make a dpi change on the local PC it is best to make sure you start a fresh remote session (instead of just re-connecting to an existing session) so that any applications that do not handle dynamic dpi changes can adjust.

    For other clients, they may change the dpi within their session and then sign out of their remote session and then back on for the change to take effect.

    -TP

    Wednesday, February 26, 2014 7:14 PM
    Moderator
  • Is there a way to alter this setting for 8.1 clients to allow dpi scaling for terminal server connections?

    Consider the use case where a client has a ultrahd 4k laptop running 8.1 -- rdp windows to servers are so small as to be illegible -- and "full screen" for a 1024x768 session is a postage stamp on the new ultra hd 14" laptop screens.

    Saturday, March 8, 2014 6:14 PM
  • Hi Flying Boz,

    I'm not sure I understand.  DPI scaling is enabled for 8.1 clients.  A person with a 4k 14" screen will likely have their local scaling set to 150-200% or larger, and then when they connect to a Server 2012 R2 their remote session will have the same scaling level.

    -TP

    Sunday, March 9, 2014 5:13 PM
    Moderator
  • This works for Windows 7 and MSTSC Shell Version 6.3.9600 and RDP 8.1 too on Windows 2012 R2?

    I tryed with this mstsc-Version, but in my case the dpi remains on 100% even if  on the windows 7 - client are configured 150%.

    In the Terminal - Session than is possible to change the setting manually, but i need that the dpi-setting is automatically the same like on the Windows 7 - client...

    Wednesday, May 28, 2014 1:05 PM
  • Hi Angus_

    As I mentioned above the auto dpi only works for Windows 8.1 Clients.  For other clients it needs to be manually changed in the session.

    -TP

    Wednesday, May 28, 2014 6:36 PM
    Moderator
  • Is there a way to turn off this behavior in Server 2012 R2? My laptop screen and my external monitor have the same resolution (1920x1080), but one is about 13" and the other is about 23". I want my rdp sessions on my external monitor to run without scaling, but I can't seem to do this without turning off scaling on my laptop.
    Wednesday, July 22, 2015 8:54 PM
  • Hate to necro this thread, but I'm fighting with this issue now that we have clients running Windows 10 on high-res screens, connecting to a 2008r2 terminal server. 

    The DPI settings are grayed out in RDP, and changing them locally on the laptop don't seem to make a difference.

    Will applying the hotfix to the server unlock the settings for people running Windows 10?

    Friday, June 24, 2016 3:08 PM
  • Hello,

         This can all be avoided if you abandon RDS server 2012 and RUN the other way.  My company has roughly 70 MS Surfaces (a Microsoft product) and due to the different versions of the Surface with different video cards, RDS 2012 has been a nightmare in terms of configuring desktop displays correctly with external monitors.  We've installed the user desktop experience on the sever which is supposed to mimic the local machine display settings (and it does to an extent) but the external 24" monitors either become blurry or cut off.  I have three separate remote desktops running Windows 7, and after installing the remote desktop display setting patch, these three users can make their own remote desktop changes in a remote environment (I never hear complaints from these three users).  As for the 2012 RDS server its a nightmare.  My suggestion here is to dump RDS 2012 and go with individual remote desktops and you'll be saving yourselves a lot of headaches and anxiety.  You can also downgrade to Server 2008, which in that case the remote desktop display patch should work for that application as well but not in 2012. 

     

    Tuesday, October 4, 2016 2:01 AM
  • So this is completely broken for users connecting to a 2012 server from Mac OS. Jee thanks Microsoft for making the 2012 fix proprietary.
    Monday, December 5, 2016 2:34 PM
  • Unfortunately Win10 clients connecting to Win2012 remote servers are in the same bad situation.

    It seems to auto-scale but not all the interface does. Thus you have Visual Studio in the remote session that scales (it can be used) but the Win2012 taskbar and some other system tools such as the Task Manager does not (and you cannot read them att all).

    Also scaling is not performant through Internet, thus scrolling code inside Visual Studio is a real pain (I'm using a 2560x1440 resolution on Win10, while an "old" Win7 client beside with 1400x1050 resolution works perfectly and very performant).

    Please, fix this because working on remote Azure VMs this way is really impossible!

    Friday, January 20, 2017 11:53 PM
  • Unfortunately Win10 clients connecting to Win2012 remote servers are in the same bad situation.

    It seems to auto-scale but not all the interface does. Thus you have Visual Studio in the remote session that scales (it can be used) but the Win2012 taskbar and some other system tools such as the Task Manager does not (and you cannot read them att all).

    Also scaling is not performant through Internet, thus scrolling code inside Visual Studio is a real pain (I'm using a 2560x1440 resolution on Win10, while an "old" Win7 client beside with 1400x1050 resolution works perfectly and very performant).

    Please, fix this because working on remote Azure VMs this way is really impossible!

    Update: after the latest updates (both sides: Win10 and Win2012) Win2012 is scaled correctly. Still not usable the RDP to Win2008 and Win7 hosts.
    Tuesday, February 28, 2017 2:17 PM
  • I have managed to connect RDP session with selected session resolution and scaling using this app:
    https://www.microsoft.com/en-us/store/p/microsoft-remote-desktop-preview/9nblggh30h88

    Saturday, March 25, 2017 3:34 AM
  • I don't understand this perspective model for configuring DPI.

    I am RDP'ing from a machine with medium dpi settings (1K) onto a machine whose native dpi settings are high (4K).  My result is very broken. It appears that the thinking RDP scaling only consider the (4K) => (1K) case. 

    What I see are gigantic icons because my RDP session is scaling everything according the scaling on my rdp-target machine. Why does it do that???

    Scaling should be strictly based on the client scaling requirements or if that is not possible, then a hybrid model that combines the rules for the client and host dpi settings.

    client

    Saturday, April 8, 2017 1:40 AM
  • Derek,

     Did you try checking the check box just above "Change only the text size" ?  The check box says "Let me choose one scaling level for all my displays"  Once we do that on RDP / Terminal Servers we are able to change the text size for each RDP user as needed.  Without installing the Feature Desktop Experience.

    • Proposed as answer by ServersIT Monday, April 10, 2017 5:03 PM
    Monday, April 10, 2017 4:48 PM