Thinfinity VDI Keyboard Configuration: ABNT2 Best Practices

Thinfinity VDI Keyboard Best Practices for ABNT2 and Multi-Layout Deployments

Overview

Thinfinity Workspace and Thinfinity Remote Desktop Server deliver Windows desktops and applications through a clientless HTML5 browser. Keystrokes therefore travel across three independent layers before they reach the application: the local OS layout on the user's device, the browser, and the Windows host on the back end. Any divergence between those layers — for example a Brazilian ABNT2 physical keyboard delivering keys to a session that has only English (US) loaded — produces wrong characters, missing accents, broken shortcuts, and failed logons that increment the Account Lockout counter.

This guide describes the recommended keyboard configuration for ABNT2 and multi-layout fleets running on Windows Server (RDS) and VDI hosts. It applies to system engineers, VDI/RDS administrators, and Thinfinity implementation teams. Following these practices ensures that the layout the user sees on the keycaps is the layout Windows actually applies — on every host, in every state (logon screen, lock screen, active session, after reconnect).

How keystrokes flow through Thinfinity

Understanding the path is essential for picking the right control point:

  1. The browser captures the keydown / keypress event from the local OS, reporting the physical key (event.code), the produced character (event.key), and the legacy keyCode field.
  2. The Thinfinity client-side JavaScript serializes the event over the WebSocket channel to the Thinfinity Server.
  3. Thinfinity Server forwards the input through the appropriate backend protocol — RDP for Windows desktops/RDS, VNC for cross-platform sessions, or the Thinfinity native protocol for direct workstation connections.
  4. On the Windows host, the keyboard driver consumes the input. If Thinfinity sent a scancode, Windows applies its own active layout. If it sent Unicode, Windows produces the literal character regardless of layout.

Two transport modes you must know

Most remote-display protocols, Thinfinity included, support two ways of representing a key:

ModeHow it worksWhen to use it
ScancodeSends the physical key position. The Windows host translates it using its own active layout.Stable production environments where you control the image and load Portuguese (Brazil ABNT2) on every host.
UnicodeSends the character produced by the local OS. The Windows host receives the literal codepoint.Mixed BYOD fleets, kiosks, or clients on macOS/iPadOS where the server has no matching layout.

Recommendation: for corporate ABNT2 environments where IT controls the Windows image, standardize on Scancode mode and load ABNT2 on every host. For mixed-device or international fleets where you cannot guarantee server-side layouts, standardize on Unicode mode and let the local OS produce the characters.

The four configuration scopes

Windows keeps keyboard configuration in four distinct scopes. Mixing them up is the single most common cause of "we changed the registry but the logon screen still shows EN-US".

ScopeRegistry / locationWhen it applies
Logon / lock screenHKEY_USERS\.DEFAULT\Keyboard Layout\PreloadBefore any user logs on; lock screen between unlocks.
New profilesC:\Users\Default\NTUSER.DATOnly the very first time a user logs on to that host.
Existing profilesHKEY_CURRENT_USER\Keyboard Layout\PreloadEvery interactive session of an existing user (persisted in NTUSER.DAT or in the FSLogix VHDX).
Machine overrideHKLM\SYSTEM\CurrentControlSet\Control\Keyboard Layout\IgnoreRemoteKeyboardLayout = 1All RDP/ICA sessions on the host once set.

How precedence resolves at session start

  1. The Thinfinity profile decides Scancode vs Unicode and sends the kbdLayout hint.
  2. If IgnoreRemoteKeyboardLayout = 1 on HKLM, Windows ignores the client hint and uses the layout loaded for that session context.
  3. The session context comes from .DEFAULT (logon screen) or HKCU\Keyboard Layout\Preload (existing user).
  4. FSLogix Profile Container preserves HKCU between session hosts; .DEFAULT and HKLM remain per-host and must be set on the gold image.

Configure ABNT2 deployments

Standardize on the correct identifier

Use the official Microsoft identifiers and never confuse the two Brazilian variants:

LayoutHex KLIDNotes
Portuguese (Brazil ABNT2)00010416Recommended for new deployments.
Portuguese (Brazil ABNT)00000416Legacy. Avoid mixing in the same fleet.
English (US)00000409Used as fallback by many remote protocols.

Configure the four scopes consistently

  • Gold image: set IgnoreRemoteKeyboardLayout = 1 in HKLM, set .DEFAULT\Preload to 00010416, and copy language settings to "Welcome screen and system accounts" via intl.cplAdministrativeCopy settings.
  • Default User profile: load C:\Users\Default\NTUSER.DAT in regedit, set Keyboard Layout\Preload\1 = 00010416, then unload. New users on the host inherit ABNT2.
  • Existing users: deliver HKCU\Keyboard Layout\Preload through a User GPO Preference so the value is rewritten at every logon.
  • FSLogix-enabled hosts: remember that HKCU is in the user's VHDX and follows them between hosts. HKLM and .DEFAULT are not — apply them via Computer GPO or the image.

Tune the Thinfinity profile

Inside the Thinfinity Workspace Access Profile (or the Thinfinity Remote Desktop Server connection settings) check the following:

  • Connection Method: pick the protocol that matches your back end. For Windows RDS/VDI, create a new RDP connection; for direct workstation deployments, use the native Thinfinity Remote Desktop protocol.
  • kbdLayout setting: if you intend to force a specific server-side layout from Thinfinity, set kbdLayout to 0x00010416 for ABNT2. Leave it blank only when you also set IgnoreRemoteKeyboardLayout = 1 on the host.
  • Keyboard mode: choose Scancode for controlled fleets where the server-side layout is guaranteed; choose Unicode for BYOD or international users.
  • Toolbar: enable the session toolbar so users can see and toggle the active server-side layout — invaluable for first-line support.
  • Browser shortcut passthrough: enable Send all keystrokes to the remote desktop to prevent the browser from swallowing combinations such as Ctrl+Alt+letter or AltGr+letter, which produce @, ?, °, and ç on ABNT2.

Reference scripts (run elevated)

These commands implement the recommended baseline on a single host. Always export the registry keys before applying them.

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Keyboard Layout" /v IgnoreRemoteKeyboardLayout /t REG_DWORD /d 1 /f
reg add "HKU\.DEFAULT\Keyboard Layout\Preload" /v 1 /t REG_SZ /d 00010416 /f
reg delete "HKU\.DEFAULT\Keyboard Layout\Preload" /v 2 /f
reg delete "HKU\.DEFAULT\Keyboard Layout\Preload" /v 3 /f
reg delete "HKU\.DEFAULT\Keyboard Layout\Preload" /v 4 /f
reg delete "HKU\.DEFAULT\Keyboard Layout\Preload" /v 5 /f

:: For the currently logged user
reg add "HKCU\Keyboard Layout\Preload" /v 1 /t REG_SZ /d 00010416 /f

A reboot is required after touching HKLM and .DEFAULT. A user logoff/logon is enough for HKCU changes.

Group Policy strategy

Hand-rolled scripts are fine for a pilot host. For production, use Group Policy Preferences (GPP) to make the configuration self-healing and auditable.

Computer GPO — for HKLM and .DEFAULT

  • Computer ConfigurationPreferencesWindows SettingsRegistryUpdate item: HKLM\SYSTEM\CurrentControlSet\Control\Keyboard Layout\IgnoreRemoteKeyboardLayout (REG_DWORD = 1).
  • Update item: HKU\.DEFAULT\Keyboard Layout\Preload\1 (REG_SZ = 00010416).
  • Delete item for any extra Preload entries (2, 3, 4…) on .DEFAULT.
  • Link to the OU that contains the RDS session hosts and Thinfinity gateway hosts. Filter with WMI if you need to skip non-VDI servers.

User GPO — for HKCU

  • User ConfigurationPreferencesWindows SettingsRegistryUpdate item: HKCU\Keyboard Layout\Preload\1 (REG_SZ = 00010416).
  • Use Item-Level Targeting to limit it to the OU or AD group affected during the pilot.
  • On FSLogix hosts, this writes the value into the user's VHDX, so it persists across hosts.

Remove competing layouts

Many "intermittent" keyboard reports are caused by Windows toggling between two preloaded layouts (Win+Space, Alt+Shift). Remove every layout that is not in scope for the user population and disable the language switching hotkeys via User ConfigurationAdministrative TemplatesWindows ComponentsText Input.

Thinfinity-specific best practices

  • Use Access Profiles, not per-user one-offs: encode keyboard mode and kbdLayout once in a profile and assign it to AD groups. Avoid drift between users.
  • Pin the gateway browser baseline: Chromium-based browsers (Chrome, Edge) handle dead keys and AltGr more reliably than older WebKit-based browsers. Recommend them for ABNT2 fleets.
  • Test from each client OS family before rollout: Windows, macOS, ChromeOS, iPadOS. AltGr behavior differs across them, especially on the @ and ? keys of ABNT2.
  • Enable the session toolbar so end users can see and toggle the active server-side layout. The Windows language indicator on the taskbar should mirror the toolbar value.
  • Document the supported layout per host pool. If you operate two pools (ABNT2 and EN-US), make sure the Thinfinity broker routes the user to the correct pool — never rely on the user choosing manually.
  • Include a smoke test in your image-build pipeline: scripted logon, type a known string with @ ? ç ã and accents, capture the result, fail the build if mismatched.

Validation checklist before going live

  1. Confirm IgnoreRemoteKeyboardLayout = 1 on every session host.
  2. Confirm .DEFAULT\Preload\1 = 00010416 and that values 2…N do not exist.
  3. Confirm HKCU\Preload\1 = 00010416 for at least three sample users (one with FSLogix container, one without, one new user).
  4. Verify the Windows logon screen shows PTB in the bottom-right indicator when reaching it through Thinfinity from a non-ABNT2 client device.
  5. Logon with a test account; type the special characters @ \ / ? ; : ' ç ã and confirm they match the keycap labels.
  6. Lock the workstation, unlock it, retype the same string. The lock screen must apply the same layout as the logon screen.
  7. Reconnect from a second client OS (e.g., macOS browser) and repeat. Both must produce the same characters.
  8. Generate three deliberate wrong-password attempts and confirm Event 4625 is logged on the host (and Event 4740 on the DC if the threshold is crossed) — proving your monitoring loop works.
  9. Have a roll-back script tested in the lab and stored next to the change record.

Common anti-patterns to avoid

  • Setting only HKCU and assuming the logon screen is fixed — it isn't. .DEFAULT must also be set.
  • Setting only .DEFAULT and assuming existing users are fixed — they aren't. HKCU must also be set.
  • Using Set-WinUserLanguageList on the gold image without disabling language sync, which silently re-adds EN-US after the first logon.
  • Trusting client-side layout on Windows-controlled fleets. If you do nothing else, set IgnoreRemoteKeyboardLayout = 1 — this is the single most effective lever.
  • Mixing ABNT and ABNT2 (00000416 vs 00010416) on the same host pool — both "work" but produce different characters on the AltGr layer.
  • Forgetting that browsers reserve some shortcuts (Ctrl+W, Ctrl+T, Ctrl+N). Use Thinfinity full-keyboard passthrough or document alternative key combinations for users.

References


    • Related Articles

    • Troubleshooting Keyboard Layout Issues in Thinfinity Workspace

      Overview Keyboard layout problems in Thinfinity Workspace sessions usually trace back to a mismatch between the client device, the Windows lock/logon screen, the user's profile, or the Thinfinity Access Profile. The wrong character appearing when you ...
    • How to Enable the Multi-Monitor Feature in Thinfinity Workspace

      Overview The multi-monitor feature in Thinfinity Workspace lets you span an RDC session across more than one physical display, so you can work with multiple windows side by side just as you would on a local desktop. This article explains how to ...
    • Thinfinity VDI Performance Troubleshooting Guide

      Overview When a user reports that their Thinfinity Workspace VDI session feels slow, the root cause can sit in many layers: the user's local device, their network, the VDI host, or the Thinfinity platform itself. This guide gives you a structured, ...
    • Remote Desktop Session Recording with Thinfinity® Workspace

      Introduction Imagine effortlessly reviewing remote sessions or guiding users through an application—Thinfinity Workspace turns this into a reality with session recording and playback features. Activate this capability in the Advanced tab within your ...
    • What's New on Thinfinity Remote Workspace 8

      Introduction Welcome to our comprehensive guide to the Thinfinity® Workspace 8. This article will introduce you to the product's groundbreaking features, new connection protocols, and enhanced user experience. Thinfinity Workspace 8 is the epitome of ...