cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Microsoft Remote Desktop client on Mac keyboard bug

Microsoft Remote Desktop client on Mac keyboard bug
13

Upvotes

Upvote
 Mar 07 2023
6 Comments (6 New)
New

Microsoft Remote Desktop client for Mac has a long and ghastly history. (Yes ghastly is the right word and this is not a typo where 'glorious' should have been used.)

 

Version 1.x had a bug whereby anybody using a Mac with a non-US keyboard was tortured by the software failure to map keys correctly to the Windows session. The most infamous examples of this where that the Mac " (speech marks) key would generate an @ (at symbol) in Windows and vice versa although a number of other incorrect key mappings also apply.

 

Version 2.x did finally fix this bug.

 

Microsoft then bought a 3rd party RDC client and this became the next Microsoft official client and I cannot remember if this was released as version 5.x or 7.x. Regardless as this was new/different code it REINTRODUCED THE SAME BUG!!!

 

Note: I have just reproduced this with Microsoft Remote Desktop 10.8.1 (2048) running under macOS Ventura 13.2.1 with as mentioned a UK Mac keyboard.

 

Literally thousands and thousands of Mac users throughout the world except the USA have been complaining about this ever since.

 

When I last was personally victimised by Microsoft with this issue many years ago I also reported this but I found that the Parallels Remote Desktop Client for Mac did not have this bug. The reason being it was not written by American programmers who are wilfully ignorant regarding international keyboard layouts.

 

Unfortunately I now once more have to use an RDC client and I am finding that the Parallels client whilst still available is not connecting to the Microsoft RDC server whereas the Microsoft client does successfully connect even if it then inflicts cruel and unusual punishment in the form of this now ancient keyboard mapping error.

 

I have however been able to prove that the RDC client for Mac available here - www.jumpdesktop.com DOES connect to the same Microsoft RDC server and DOES NOT have this keyboard mapping bug. However the JumpDesktop client is a chargeable product.

 

Microsoft over the decades has in a number of cases committed grave offences against Mac-kind but in more recent times has been comparatively friendly to the Mac using community. Why therefore is this bug which affects potentially BILLIONS of people around the world i.e. anyone who does not have a Mac with an American keyboard still not been fixed?

 

PLEASE FIX IT AT LONG LAST!

 

How to reproduce.

1. Connect a non-US keyboard to a Mac, this could be a USB or Bluetooth keyboard, it does not have to be an Apple brand keyboard but genuine Apple keyboards would be the most common use.

2. The Mac should be configured to use the relevant keyboard layout - in my case this is UK but I know that it affects all other non-US layouts e.g. French, German, etc.

3. Connect to a Windows RDC session

4. On the Windows desktop open an app like Wordpad

5. On the Mac type in to the Wordpad document abcdefghijklmnopqrstuvwxyz these all map correctly. Now on the Mac type the @ (at) symbol, in Window you will instead see the " (speech marks) symbol, now on the Mac type the " (speech marks) symbol, in Windows an @ (at) symbol will appear. As mentioned other keys like the \ (back slash) are also incorrectly mapped.

6. Download the trial version of the JumpDesktop client

7. Use JumpDesktop to connect to the SAME Windows RDC server

8. Repeat the same typing test in to Wordpad, this time all the keys are correctly mapped with no settings having to be altered either on the Mac or in Windows.

 

Conclusion, Microsoft programmers are at fault.

Comment
Comments
Benjamin_Moles
Copper Contributor
‎Apr 12 2023 06:40 AM
‎Apr 12 2023 06:40 AM

We are affected by this issue as well. It will be useful having it fixed.

Vincent_Verdun
Copper Contributor
‎Jun 23 2023 05:26 AM
‎Jun 23 2023 05:26 AM

Yes ! and that : 

Hi,

 

When using the Macintosh "Microsoft Remote Desktop" (French ?) I have a keyboard problem with Powershell : my keyboard does not send anything to the powershell session if the keyboard mode is "Unicode" in the "Keyboard Mode" "Connections" menu.

I must switch to "Scancode" to succeed but "Scancode" is not well mapped with Mac French keyboard which become a nightmare to type powershell command !

 

please debug it Microsoft ! 

 

Thank you !

g8610g
Copper Contributor
‎Aug 10 2023 02:58 PM
‎Aug 10 2023 02:58 PM

I have problems with keyboard input in certain apps using rdp. In windows it works from iPad. When I start Zbrush and power shell keyboard input is impossible. Nothing happens. Is this the same cause?

 

going back to windows keyboard input returns.. so strange

BHK423542353451250
Copper Contributor
‎Dec 06 2023 12:04 AM
‎Dec 06 2023 12:04 AM

Same problem but only when connecting to a Windows 11 client... Amazing how Microsoft was never able to build reliable software...

AndyHibbs
Brass Contributor
‎Dec 15 2023 05:31 AM
‎Dec 15 2023 05:31 AM

We've been suffering this problem for years. We've mostly got around the problem by asking the users to set the keyboard mode to Unicode, which allows enough of the UK Mac keyboard to be mapped as the average user needs, including the '@' sign and speech marks.

 

However, as developers we use Scancode, which allows us to do things in calculations that Unicode doesn't. We've uploaded a custom UK keyboard to each RemoteApp server, which again does an OK, but not perfect job.

 

Now we have a problem for users authenticating by OAUTH 2 for Microsoft 365 within our apps. Typing into a web browser within FileMaker using Unicode results in a 'Before typing, press Tab or click in a field' message, which is a standard FileMaker error when trying to enter data without having the cursor in a field. However, there are no fields in this case, just the native Microsoft Edge engine based web viewer.

 

Swap the setting to Scancode and all works fine, except the keyboard mappings then rely on the custom keyboard, which has to be selected within a floating language bar and set for each session (if it opens at all, or with the text displaying to change it, which is the most common annoyance).

 

We're now playing with modal window settings to see if we can get around this (once again).

 

For years Jump Desktop from PhaseFive Systems has allowed a 'Match Mac Keyboard', or an extensive list of international keyboards, to select from for each connection. It is very obvious that this is not a priority for Microsoft, despite the awful user experience outside of the US.

Sacha81
Copper Contributor
‎Mar 15 2024 02:17 AM
‎Mar 15 2024 02:17 AM

I have the same problem, also # is not working from my mac

Similar Ideas
No similar ideas