Windows April 2026 RDP warning: unknown publisher, quick rollback, and the proper GPO fix

So what changed?#

Starting with the April 14, 2026 Windows security updates, Microsoft changed how .rdp files open. If you're used to handing users an RDP file and telling them to double-click it, you probably noticed Windows suddenly got a lot louder about it.

Microsoft documents the change in the new RDP security warning write-up and in the monthly update history pages, including Windows 11 version 26H1 and Windows 10 ESU. The short version is:

the first time a user opens an .rdp file after the update, they get a new educational warning
every .rdp launch now gets a security dialog before the connection starts
requested redirections are turned off by default unless the user explicitly turns them on
unsigned files show up as Unknown publisher

From a security perspective, fair enough. From an admin perspective, it immediately wrecks the old lazy workflow where you mail out an .rdp file and pretend that counts as deployment.

One important detail: Microsoft says this change only affects connections started by opening an .rdp file. If someone opens mstsc.exe and types a hostname manually, that part is unchanged.

The temporary fix#

If your helpdesk is getting lit up and you need people working again today, there is a temporary rollback.

Microsoft says you can revert the new dialog behavior by setting RedirectionWarningDialogVersion=1 under:

HKLM\Software\Policies\Microsoft\Windows NT\Terminal Services\Client

You can set it with PowerShell like this:

Set-RdpWarningRollback.ps1

New-Item `
  -Path 'HKLM:\Software\Policies\Microsoft\Windows NT\Terminal Services\Client' `
  -Force | Out-Null
 
New-ItemProperty `
  -Path 'HKLM:\Software\Policies\Microsoft\Windows NT\Terminal Services\Client' `
  -Name 'RedirectionWarningDialogVersion' `
  -PropertyType DWord `
  -Value 1 `
  -Force

If you need to spray that out fast, push the same DWORD with Group Policy Preferences, your RMM, or whatever blunt object you already use for registry deployment.

This is the band-aid. It buys you time. It is not the real fix.

Microsoft is pretty explicit that a future Windows update might remove support for that setting. So yeah, use it if you need breathing room, but don't marry it.

The fix that actually sticks#

The real answer is to stop shipping unsigned .rdp files like it's still 2014.

What you actually want is:

create a signing certificate you control
sign the final .rdp file
push trust for that certificate to clients
copy the signed .rdp file to users with GPO

Microsoft documents the pieces separately. This is just the sane way to glue them together for an internal environment.

Create a local signing cert#

If you already run AD CS and have a proper internal code-signing cert template, use that. If not, a local self-signed code-signing cert is enough for internal .rdp distribution as long as you deploy trust to the clients.

Create the cert on the admin machine you want to use for signing:

New-RdpSigningCert.ps1

New-Item -ItemType Directory -Path 'C:\RDP-Signing' -Force | Out-Null
 
$cert = New-SelfSignedCertificate `
  -Subject 'CN=Internal RDP Publisher' `
  -Type CodeSigning `
  -CertStoreLocation 'Cert:\CurrentUser\My' `
  -KeySpec Signature `
  -KeyAlgorithm RSA `
  -KeyLength 2048 `
  -HashAlgorithm SHA256 `
  -NotAfter (Get-Date).AddYears(3)
 
Export-Certificate `
  -Cert $cert `
  -FilePath 'C:\RDP-Signing\internal-rdp-publisher.cer'

That exports the public certificate. That's the bit you push to clients.

The private key stays on the machine doing the signing. Do not copy that around the domain unless you enjoy creating dumb problems for yourself later.

You'll also want the SHA1 thumbprint for the optional trusted publisher policy:

Get-RdpPublisherThumbprint.ps1

$sha1Thumbprint = ($cert.Thumbprint -replace '\s', '')
$sha1Thumbprint

Yes, the policy still talks about SHA1 thumbprints even though modern rdpsign uses /sha256. That's Microsoft's naming, not a typo.

Sign the damn RDP file#

Build the .rdp file first. Put all your settings in it first. Then sign it.

If you edit the file after signing it, sign it again. A signature only proves the file hasn't changed since it was signed. That's the whole point.

Microsoft's rdpsign tool is the official way to do this. On current Windows versions, use /sha256 and pass the certificate's SHA256 hash with spaces removed.

Test first:

Test-RdpSigning.cmd

rdpsign /sha256 <certificate-sha256-hash-without-spaces> /l C:\RDP-Signing\AdminBox.rdp

Then actually sign it:

Sign-RdpFile.cmd

rdpsign /sha256 <certificate-sha256-hash-without-spaces> C:\RDP-Signing\AdminBox.rdp

Two notes here:

rdpsign overwrites the input file
if you copy the hash from the certificate UI, strip the spaces out of it before you use it

Push it out with GPO#

Now make the clients trust the publisher and give them the signed file.

1. Push the certificate#

In Group Policy Management, create or edit a GPO linked to the computers that should trust your signed .rdp files.

Import internal-rdp-publisher.cer into:

Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities
Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Publishers

For a self-signed cert, doing both matters. Root trust handles the chain, and Trusted Publishers handles the publisher trust.

2. Optionally pin trusted `.rdp` publishers#

If you want to be stricter, enable:

Specify SHA1 thumbprints of certificates representing trusted .rdp publishers

That policy exists under both:

Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Connection Client
User Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Connection Client

Add the SHA1 thumbprint you pulled earlier. Microsoft says this policy overrides the more general Allow .rdp files from valid publishers and user's default .rdp settings behavior.

3. Push the signed `.rdp` file#

Use Group Policy Preferences to copy the signed file to the user.

The clean path for that is:

User Configuration > Preferences > Windows Settings > Files

Create a new file preference with:

Action: Replace
Source file(s): \\yourdomain\netlogon\RDP\AdminBox.rdp
Destination file: %DesktopDir%\Admin Box.rdp

You can obviously swap the destination for Start Menu, a tools folder, or whatever makes sense in your environment. I still prefer pushing the actual .rdp file instead of just a shortcut because it's easier to replace cleanly when something changes.

Test it like a sane person#

Don't test this on the same admin box where you created everything and then act surprised when trust magically already exists.

Use a normal client machine that gets the GPO. Then:

Refresh-Policy.ps1

gpupdate /force

After policy refresh:

confirm the certificate is present in Trusted Root Certification Authorities and Trusted Publishers
confirm the user received the signed .rdp file from GPO
open that deployed .rdp file
verify the publisher is your internal publisher and not Unknown publisher

If it still looks wrong, check the boring stuff before you start blaming Windows:

the client might still be opening an old unsigned local copy
the file might have been edited after signing
the GPO might have copied the wrong file
the thumbprint policy might contain spaces or a typo
the cert might not have landed in the right store yet

If the machine is being stubborn, do one reboot before you lose an hour to unnecessary drama.

A couple gotchas before you call it done#

This fix makes the publisher verifiable. It does not magically make a bad .rdp file safe.
If you renew or replace the signing cert later, redeploy the new public cert and update any thumbprint-based policy.
If you already have AD CS, using an issued code-signing cert is cleaner than living forever on a self-signed one.
If you just need to stop the bleeding today, the registry rollback works. If you want a setup that survives future updates, sign the file and push trust properly.