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 type @, ?, ç, or ã can also surface as account lockouts, because every wrong character at the password prompt counts as a failed logon.

This article walks you through a structured triage and the registry-level fixes for the four layers where the layout is decided: the Windows logon/lock screen (.DEFAULT), the user profile (HKCU), the host (HKLM), and the Thinfinity Access Profile.

Before you change anything

Golden rule: never change passwords or registry keys without first capturing what is currently configured. The snapshot script below is the same one you attach to a support escalation.

Always capture the current state of the host before editing the registry. The snapshot doubles as a rollback reference and as evidence to attach to a support escalation.

Run this snapshot script on the affected session host as a local administrator:

@echo off
set OUT=C:\Temp\kbd_snapshot_%COMPUTERNAME%.txt
mkdir C:\Temp 2>nul
echo === HOST: %COMPUTERNAME% === > "%OUT%"
echo --- HKLM Keyboard Layout --- >> "%OUT%"
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Keyboard Layout" >> "%OUT%" 2>&1
echo --- .DEFAULT Preload --- >> "%OUT%"
reg query "HKU\.DEFAULT\Keyboard Layout\Preload" >> "%OUT%" 2>&1
echo --- HKCU Preload --- >> "%OUT%"
reg query "HKCU\Keyboard Layout\Preload" >> "%OUT%" 2>&1
powershell -NoProfile -Command "Get-WinUserLanguageList | Format-List" >> "%OUT%" 2>&1

Export each affected key so you can re-import it if needed:

reg export "HKU\.DEFAULT\Keyboard Layout\Preload"          C:\Temp\backup_default_preload.reg /y
reg export "HKCU\Keyboard Layout\Preload"                  C:\Temp\backup_hkcu_preload.reg /y
reg export "HKLM\SYSTEM\CurrentControlSet\Control\Keyboard Layout" C:\Temp\backup_hklm_keyboard.reg /y

60-second triage

Use these questions to classify the problem and jump to the right section.

Symptom-to-cause map

Once the triage above pointed you to the right layer, use this map to match a specific symptom to its most likely cause and the test that confirms it.

Fix the logon and lock screen

The Windows logon and lock screens read from the .DEFAULT hive, not from any user profile. This is the layer most often responsible for password-prompt lockouts.

Inspect

reg query "HKU\.DEFAULT\Keyboard Layout\Preload"
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Keyboard Layout" /v IgnoreRemoteKeyboardLayout

Expected values for Brazilian ABNT2:

• Preload\1 = 00010416 (REG_SZ)
• IgnoreRemoteKeyboardLayout = 0x1 (REG_DWORD)

Visual confirmation

• Connect to the host through Thinfinity from a non-ABNT2 client device — a US-keyboard laptop is ideal. If the bottom-right indicator on the Windows logon screen shows PTB, that is the proof that .DEFAULT is in charge — not the client.
• If the indicator still shows ENG even with the registry set, capture HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options for any custom Welcome screen overrides, and check whether Copy settings → Welcome screen and system accounts was applied via intl.cpl → Administrative.

Apply

1. Run the snapshot script in the previous section.
2. Open an elevated command prompt and apply the values:

   reg add "HKU\.DEFAULT\Keyboard Layout\Preload" /v 1 /t REG_SZ /d 00010416 /f
   for %i in (2 3 4 5) do reg delete "HKU\.DEFAULT\Keyboard Layout\Preload" /v %i /f 2>nul
   reg add "HKLM\SYSTEM\CurrentControlSet\Control\Keyboard Layout" /v IgnoreRemoteKeyboardLayout /t REG_DWORD /d 1 /f

3. Reboot the host. The change does not take effect until the system reloads the .DEFAULT hive.

Fix existing user profiles

Once a profile has stored a layout in HKCU\Keyboard Layout\Preload, fixing .DEFAULT alone is not enough — the existing profile keeps using its stored value.

Inspect the current user

reg query "HKCU\Keyboard Layout\Preload"
reg query "HKCU\Keyboard Layout\Substitutes"

Inspect another user (admin context)

wmic useraccount where name="user.name" get sid
reg query "HKU\<SID>\Keyboard Layout\Preload"

Inspect when the user is not logged on

Load the offline hive (mount the FSLogix VHDX first if applicable):

reg load HKU\OfflineUser "C:\Users\username\NTUSER.DAT"
reg query "HKU\OfflineUser\Keyboard Layout\Preload"
reg unload HKU\OfflineUser

Apply

• One user, one host: run reg add "HKCU\Keyboard Layout\Preload" /v 1 /t REG_SZ /d 00010416 /f while the user is logged on, then have them log off and back on.
• Population-wide: deploy a User GPO Preference (Update item on HKCU\Keyboard Layout\Preload\1 = 00010416). Add Item-Level Targeting to scope by AD group during a pilot.
• Logon script: a .cmd that runs the same reg add at every logon — slower than GPP but audit-friendly.

Inspect the Thinfinity Access Profile and browser

If keyboard input is correct with mstsc.exe to the same host but wrong through the Thinfinity browser session, the issue is in the profile or the browser, not in Windows.

Profile checks

1. In Thinfinity Workspace Manager, open Access Profiles and select the profile in use. See How to Create a New RDP Connection in Thinfinity Workspace for context on profile structure.
2. On the Connection tab, confirm the connection method matches the back-end (RDP for Windows RDS/VDI).
3. On the Keyboard tab, verify kbdLayout (e.g. 0x00010416 for ABNT2), the keyboard mode (Scancode vs Unicode), and the pass-through option.
4. If kbdLayout is left blank, the host's IgnoreRemoteKeyboardLayout setting is what decides — make sure it is set to 1.

Browser-layer checks

• Reproduce the issue in two browsers (Chrome and Firefox). If only one is affected, switch the recommended browser or update to the latest Chromium build.
• Open the developer console (F12 → Console) on a focused field and type the failing key. event.code is the physical key; event.key is the character. If event.key is already wrong before reaching Thinfinity, the local OS layout is the culprit.
• Test in an Incognito/Private window with extensions disabled — keyboard remappers, Vimium, and accessibility helpers can intercept keys.

Client OS checks

• On the user's client device, verify the active OS layout (Windows: taskbar indicator; macOS: menu bar). It must match the keycaps before any debugging on the server side.
• On macOS, the option key produces accented characters at the OS level — those reach the browser already as Unicode and may double-process on the server. For mac users, prefer Unicode mode in the Access Profile.
• On iPadOS, external keyboards may signal the wrong layout to the browser. Test with the on-screen keyboard to isolate whether the issue is the external keyboard or iPadOS itself.

When users are getting locked out

A layout mismatch on the password prompt looks like a security incident: every wrong character counts toward the Account Lockout Threshold. Confirm the chain before treating it as a brute-force.

1. Pick one user that locked out today and note the timestamp.
2. On the session host, search the Security log for Event ID 4625 (failed logon) around that timestamp.
3. On the Domain Controller that recorded the lockout, search for Event ID 4740.
4. In each 4625, check Logon Type 10 (RemoteInteractive — what Thinfinity sessions produce) and the Source Network Address: it should be the Thinfinity gateway IP.
5. If the source is the Thinfinity gateway and the user later logged in successfully without changing their password, you have circumstantial evidence that the password was correct but transcoded — i.e., a layout mismatch.

Useful PowerShell to pull the last 100 failed logons:

Get-WinEvent -FilterHashtable @{LogName="Security"; Id=4625} -MaxEvents 100 |
  Select-Object TimeCreated,
    @{n="User";   e={$_.Properties[5].Value}},
    @{n="Source"; e={$_.Properties[19].Value}},
    @{n="Reason"; e={$_.Properties[8].Value}}

In a multi-DC environment, find which Domain Controller actually processed the lockout — Event 4740 only lives there:

Get-ADUser -Identity user.name -Properties LockedOut, AccountLockoutTime, LastBadPasswordAttempt

Get-ADDomainController -Filter * | ForEach-Object {
  Get-WinEvent -ComputerName $_.HostName `
               -FilterHashtable @{LogName="Security"; Id=4740} `
               -MaxEvents 5 -ErrorAction SilentlyContinue
}

Never log a user's password or its perceived form. The goal is to confirm that lockouts coincide with Thinfinity sessions and stop after the layout fix is applied — not to reproduce the password.

If you are also evaluating whether real brute-force attempts are mixed in, see Brute Force Detection in Thinfinity Workspace.

Multi-host pools and FSLogix

In host pools, drift is common: one image was rebuilt last quarter and got the new GPO, the other still runs the old image. FSLogix complicates the picture because it carries HKCU between hosts but not HKLM or .DEFAULT.

Run a host-pool sweep to find the outliers:

Invoke-Command -ComputerName (Get-Content hosts.txt) -ScriptBlock {
  Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Keyboard Layout" -ErrorAction SilentlyContinue |
    Select PSComputerName, IgnoreRemoteKeyboardLayout
}

For FSLogix-specific cases:

• Confirm the user's container path under HKLM\SOFTWARE\FSLogix\Profiles → VHDLocations and that it mounted at the latest logon (event log: Microsoft-FSLogix-Apps/Operational).
• Mount the VHDX offline, load NTUSER.DAT, and inspect Keyboard Layout\Preload.
• If a user's container has the wrong value but the running session is correct because Group Policy Preference rewrites it on logon, leave GPP as the responsible owner — but document the asymmetry so a future change does not regress the fix.
• Remember: HKLM and .DEFAULT live on the host's C: drive — not in the FSLogix container. Re-imaging without re-applying these will break logon screens again.

Validate the fix

1. Apply the change in the smallest possible scope first — one host or one OU — before rolling it out widely.
2. Force a full logoff (not disconnect) of any test user. Reboot the host if you touched HKLM or .DEFAULT.
3. Reconnect through Thinfinity from a non-ABNT2 client device. The bottom-right indicator on the Windows logon screen must show the expected layout (e.g. PTB).
4. Type a known string that exercises the AltGr layer — for example @ ? / \ ; : ' ç ã — and capture a screenshot.
5. Lock the workstation, unlock it, and repeat the same string. Both states must agree.
6. Run the snapshot script again and diff against the pre-change capture. The only differences should be the keys you intended to change.
7. Monitor Event 4625 for 24-48 hours after the fix to confirm the failure rate dropped.

Rolling back

If the change introduces a new problem, restore the keys from the backup files you exported earlier:

reg delete "HKLM\SYSTEM\CurrentControlSet\Control\Keyboard Layout" /v IgnoreRemoteKeyboardLayout /f
reg import C:\Temp\backup_default_preload.reg
reg import C:\Temp\backup_hkcu_preload.reg
reg import C:\Temp\backup_hklm_keyboard.reg

Reboot the host after any rollback that touched HKLM.

Quick reference

If the issue persists

If the layout is still wrong after applying the fixes above, gather the following before contacting Cybele Software support so the case can be triaged in a single round-trip:

• Thinfinity product and version (build number from the About menu).
• Back-end protocol (RDP/VNC) and target host OS.
• Client OS and browser (e.g. Windows 11 23H2 + Chrome, macOS 14 + Safari).
• Export of the affected Access Profile from the Thinfinity Workspace Manager.
• Snapshot output from at least one affected host.
• Exact reproduction steps (logon screen vs session, which keys, which user) with screenshots.
• Event 4625/4740 excerpts around the failure window if authentication is impacted.
• Which sections of this article you executed and the outcome of each — including any workarounds you tried.
• Number of users affected and business impact.

References

• Microsoft Learn — Keyboard identifiers and input method editors for Windows
• Microsoft Learn — How regional and language options apply on Terminal Server / RDS
• Microsoft Learn — Audit logon events (Event 4625)
• Microsoft Learn — Audit account lockout (Event 4740)
• Microsoft Learn — Configure FSLogix Profile Containers
• Cybele Software — Thinfinity Remote Desktop Server keyboard reference
• Cybele Software — kbdLayout values
• Cybele Software — Thinfinity Workspace v8 documentation