Windows 11 RDP privacy consent prompts for clipboard redirection in managed business environment

Michael McCoy 0 Reputation points
2026-05-15T03:24:02.9433333+00:00

We are experiencing disruptive privacy consent prompts in Windows 11 when using Remote Desktop (mstsc.exe), specifically relating to clipboard/local resource sharing.

Environment:

  • Company-managed Windows 11 PCs
  • Cisco AnyConnect VPN to office
  • Internal RDP only
  • Traditional mstsc.exe client
  • Devices are company-owned and locked down
  • Clipboard sharing is required for normal workflow

We are trying to determine:

  1. Whether Microsoft provides a supported method to suppress or permanently approve these prompts in managed enterprise environments.
  2. Whether there are Group Policy or registry settings related to this behavior.
  3. Whether this is expected behavior moving forward in newer Windows 11 builds.

This appears related to the newer Windows 11 privacy consent/security model.

Any guidance from Microsoft or administrators managing similar environments would be appreciated as this is affecting our workflow and for our situation we feel it is not necessary.

Any guidance from Microsoft or administrators managing similar environments would be appreciated as this is affecting our workflow and for our situation we feel it is not necessary.

Windows for business | Windows Client for IT Pros | User experience | Remote desktop clients
0 comments

3 answers

Sort by: Oldest
Most helpful Newest Oldest
  1. Tracy Le 12,005 Reputation points Independent Advisor
    2026-05-15T05:49:13.3033333+00:00

    Hello Michael McCoy,

    Now Windows requires stronger trust signals before allowing clipboard sharing over RDP. A supported, long-term approach is to sign your internal .rdp files with a corporate certificate (preferably using modern hashes like SHA-256) and enforce trusted publishers via Group Policy under Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Connection Client.

    If signing and PKI rollout aren't immediately possible, you can deploy a temporary registry compatibility option to a pilot group by navigating to HKLM\Software\Policies\Microsoft\Windows NT\Terminal Services\Client and creating a REG_DWORD named RedirectionWarningDialogVersion set to 1. Please treat this as a short-term workaround only, as it reduces the protection of the new consent model and will likely be deprecated in future Windows builds.

    If this policy guidance helps stabilize your administrative deployment, please remember to click "Accept Answer".

    Tracy Le.

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments
  2. Michael McCoy 0 Reputation points
    2026-05-15T05:57:08.54+00:00

    Hi, thank you for your response. We have tried signing the rdp files, we set up a CA server within the domain and tried signing the rdp files (this was suggested to us when we first experienced the change) unfortunately this does not work. The registry change you suggested does work but it has been suggested to me that future updates may stop it from working. I understand the thinking behind this update and if we were not using locked down company supplied pc's to connect to the office I would leave it in place but in our circumstance it is just not necessary, I believe Microsoft should make this optional

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments
  3. Tracy Le 12,005 Reputation points Independent Advisor
    2026-05-15T08:25:23.31+00:00

    Hello Michael McCoy,

    If your signed .rdp files still trigger the consent dialog, it usually means the client can’t validate the certificate trust chain or the thumbprint you put into Group Policy is malformed. Make sure your internal Root CA is trusted on the Windows 11 endpoints, and that the certificate you use to sign .rdp files is code‑signing / digital‑signature certificate with an accessible private key. Prefer SHA-256 thumbprints where supported and confirm your rdpsign tool on the target OS accepts /sha256.

    When you paste the certificate thumbprint into Group Policy, strip out all spaces and any hidden Unicode characters (for example the invisible LTR mark you can accidentally copy from MMC) - those invisible characters will make validation fail silently. Until you’ve fully validated the PKI trust chain, using the RedirectionWarningDialogVersion registry bypass via Group Policy Preferences is a practical short-term workaround, but only after pilot testing and documenting the security trade-offs.

    I hope the response provided some helpful insight. If it clarified the issue for you, please consider marking it as Accept Answer so others with the same issue can find the solution. Feel free to leave a comment if you need further information.

    Tracy Le.

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.