If you are working on a macOS device with the Azure Virtual Desktop Client using a non US keyboard layout you will sooner or later find out that the option key mapping of specific characters is not working. It seems to work fine when you are using a US keyboard layout but in my case a German layout (QWERTZ) is not working properly.
It is important to understand that there are two different keyboard modes available how a pushed key is interpreted in the remote session.
Scancode
- A scancode is a hardware-specific code that identifies a key pressed or released on a keyboard.
- It is generated by the keyboard hardware when a key is pressed or released and is sent to the operating system or other lower-level software for interpretation.
- Scancodes do not represent characters or text directly. Instead, they represent key actions, such as pressing or releasing a specific key.
- Different keyboards and architectures can have different scancode sets, which are then interpreted by the operating system to determine the corresponding character, function, or control key.
Unicode
- Unicode is a universal standard that represents characters and symbols across different languages and platforms.
- Unicode is at a higher level than scancodes, focusing on what characters should appear in a text or document, rather than the specific key actions that produced them.
- It is used to encode text in a consistent way, allowing for the representation of virtually any character or symbol used in written languages.
Solution
For making the special characters appear inside the remote session the solution is to change the default keyboard mode (Scancode) to Unicode. This can be done over the GUI (Connections > Keyboard Mode) or the keyboard shortcut (^⌘U).
Note: With the keyboard mode configured to Unicode most of the special characters are working (e.g. [],{},|, ?). Unfortunately the backlash (\) is still not working. My current workaround is to use a clipboard manager like Maccy with custom pins to access the backslash character in a faster way. I hope this will get fixed in a newer version of the Remote Desktop Client for macOS.
This behaviour is mentioned in the Microsoft documentation as well. I just wanted to share that piece of information because I could not find it in the first place.