Microsoft dropped its April 2026 cumulative updates, and suddenly help desks everywhere lit up. Users started seeing alarming security prompts every time they opened a .rdp file. Nothing was hacked. Nothing was broken. So, here’s the fix — background reading comes later for those who want it.
TL;DR — Just Fix It
Step 1: Kill the repeating warning (machine-wide)
Run this from an elevated command prompt, or deploy it via GPO/RMM:
reg add "HKLM\Software\Policies\Microsoft\Windows NT\Terminal Services\Client" /v RedirectionWarningDialogVersion /t REG_DWORD /d 1 /f
Or set it manually in Registry Editor:
HKLM\Software\Policies\Microsoft\Windows NT\Terminal Services\Client Value: RedirectionWarningDialogVersion = DWORD 1
Step 2: Kill the one-time first-launch dialog (per user)
REG ADD "HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client" /v RdpLaunchConsentAccepted /t REG_DWORD /d 1 /F
Push this via logon script, RMM, or GPO Preferences targeting the HKCU hive.
Step 3: Deploy at scale via GPO
Instead of touching every machine, use Group Policy Preferences. Navigate to Computer Configuration > Preferences > Windows Settings > Registry, create registry items for both keys above, then link and force a refresh. From there, machines pick it up on the next policy cycle automatically.
Step 4: The permanent fix — sign your RDP files
Ultimately, the only fully supported long-term solution is digitally signing your internal .rdp files with a code-signing certificate (EKU = Code Signing) from your internal CA. Then add the SHA1 thumbprint to this GPO policy:
Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Connection Client > “Specify SHA1 thumbprints of certificates representing trusted .rdp publishers”
Additionally, enable the companion policy: “Allow .rdp files from valid publishers and user’s default .rdp settings.” After that, signed files open cleanly with zero warning dialogs.
⚠️ Important: Microsoft explicitly warns that the registry workarounds in Steps 1 and 2 may stop working in a future update. So, treat them as a band-aid while you get certificate signing sorted.
Triage Checklist
Before touching any registry keys, first confirm the issue is the April 2026 cumulative update. Check Settings > Windows Update > Update History for KB5083769 on Windows 11, or the equivalent CU for your OS build. Next, identify how each affected user launches RDP — .rdp file, desktop shortcut, or mstsc.exe directly. Then deploy the registry workaround for immediate relief and kick off your certificate signing project in parallel. Finally, plan to retire the registry workaround once properly signed .rdp files reach production.
What If Users Launch RDP Directly?
Interestingly, these new warnings only affect .rdp file launches. Consequently, users who open mstsc.exe and type a server name directly won’t see any new prompts at all. So, if some teams are calling in and others aren’t, that’s almost certainly the reason. Additionally, developers using the Remote Desktop ActiveX Control via mstscax.dll have a dedicated control path through the IMsRdpExtendedSettings interface using the RedirectionWarningDialogVersion property.
What Actually Changed
Specifically, the April 2026 update tied to CVE-2026-26151 added new warning dialogs to the RDP client. Now, every time a user opens an .rdp file, Windows displays the remote computer address alongside a checklist of requested local resource redirections — clipboard, drives, printers, cameras. Additionally, every redirection is disabled by default, so users must manually opt in before anything gets shared. The first launch also fires a one-time educational dialog about RDP phishing risks. It only appears once per user account, but that’s small comfort when the help desk phone is already ringing off the hook.
Why Microsoft Did This
Bluntly, RDP phishing is a real and ugly problem. Microsoft documented a 2024 Midnight Blizzard campaign where attackers sent signed .rdp files through phishing emails, connecting victims directly to attacker-controlled servers. Those files silently mapped local drives, clipboard contents, smart cards, and webcams back to the attacker. So, yes — Microsoft had a legitimate reason to act. That said, it still doesn’t feel great when 200 users are calling IT at 9 AM on a Tuesday morning.