Remote Desktop, High DPI & Dynamics GP
Users of Microsoft Dynamics GP on high dots per inch (DPI) displays, such as Surface Pro tablets, have probably seen Steve Endow’s excellent solution to scaling issues that occur and render GP difficult to use. If you’re using a local installation of GP on one of these devices and haven’t seen that solution, I highly recommend viewing the article so you can avoid the need to change your screen resolution or limit yourself to only working on an external monitor.
The solution involves modifying the Windows registry to tell Windows to prioritize the use of an external manifest file for applications if available. Steve’s article provides the manifest file you need to make GP usable on a high DPI display. This works well for local installations of GP on these devices.
What about users who connect to a Remote Desktop server to run Dynamics GP from a high DPI display? Unfortunately, they’ve been out of luck because Remote Desktop sessions inherit the resolution and scaling settings of the local machine. Implementing the external manifest solution on the Remote Desktop server doesn’t help because the display inheritance behavior takes priority.
In my testing, I tried numerous scaling and resolution changes as well as a variety of Remote Desktop clients, but until recently, the only solution that worked was to reduce the Surface Pro resolution or use an external monitor with a lower resolution. This wasn’t satisfactory because I have clients that want to work exclusively on a Surface Pro, Remote Desktop Protocol (RDP) to a server and run GP without having to change their display resolution. A typical use case is that they’re traveling light and need to do something in GP remotely. Fortunately, I found the solution, which seems rather obvious now since it’s just a variation on what Steve already worked out. I wanted to share it with the GP community because I’m sure others have encountered the issue and I think this complements Steve’s solution nicely.
First, I need to give credit where it’s due. My solution is taken in part from an article by Dale Hayter on his blog at blackforce.co.uk. I was fortunate enough to realize it could be applied to solve a problem in the world of GP.
The solution is to make the registry change on the Surface Pro like you would for a local installation:
- Open Registry Editor.
- Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide.
- Add a DWORD (32Bit) called PreferExternalManifest.
- Give it a hex value of 1.
- Create a manifest file called Mstsc.exe.manifest with the following contents:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="184.108.40.206" processorArchitecture="*" publicKeyToken="6595b64144ccf1df" language="*">
<assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.21022.8" processorArchitecture="amd64" publicKeyToken="1fc8b3b9a1e18e3b">
<requestedExecutionLevel level="asInvoker" uiAccess="false"/>
- Place the manifest file in the same folder as the Remote Desktop client executable, C:\Windows\System32.
- Alternatively, you can copy mstsc.exe to a new folder and place the manifest file there if you don’t want to alter the default behavior of your Remote Desktop client. If you do this, you also will need to create a subfolder called en-US—or whatever language you use—and copy the mstsc.exe.mui file from C:\Windows\System32\en-US. The remote desktop client won’t run without this.
In my testing, however, I haven’t experienced any negative effects from simply placing the manifest file in the original mstsc.exe location.
- One note of caution: Windows Update may remove the PreferExternalManifest setting. If you notice this solution has stopped working, double-check the registry. You may want to export the registry key to a .reg file for easy import in the future.
One last bit of good news: This solution works with RDWeb and RemoteApp implementations in addition to direct Remote Desktop client connections.