In an office, the per-PC checkbox does not scale and a downloaded REG file does not belong. Group Policy offers two honest fleet routes: give every server a trusted certificate so the question never arises, or deploy the trust decision centrally. Here is how to choose.
Twenty users, twenty popups, twenty private decisions about whether to click Yes - that is not a security posture, it is twenty habits forming without you. The fleet answer comes in two sizes. The complete answer is server-side: certificates from your internal authority, issued automatically, so clients verify silently. The smaller answer is client-side: the same CertHash trust the checkbox writes, deployed by policy from the centre. This page lays out both, and names the one fleet shortcut that must never be taken.
With an Active Directory Certificate Services authority in place, create a certificate template for Remote Desktop use and let servers enrol automatically through Group Policy. Each server receives a certificate in its own name, issued by the CA every domain PC already trusts, and binds it to its RDP listener. The result generalises the single-server fix from this guide set: no popup, for any user, on any PC, ever - not because warnings were lowered, but because the identity check now passes.
Renewal rides along: auto-enrolment renews before expiry, so the recurring popup-after-renewal problem disappears with it. This is the only route that removes the question instead of managing the answers, and at fleet scale it is worth its setup cost.
No CA, or a handful of workgroup servers that policy still reaches? Group Policy Preferences can write registry values to every user - including the exact entry the checkbox writes: a CertHash binary value under HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Servers, in a key named for your server. You are not deploying a weaker setting; you are deploying a verified decision: capture the fingerprint from the real server's certificate yourself, and let policy repeat it faithfully.
Carry the honest limits with you. Deployment does not verify anything - if you pin the wrong fingerprint, you have now pinned it wrongly everywhere at once. And when the server's certificate changes, the policy must be updated, or the whole fleet meets the returning-popup morning together. Keep the policy small, named after the server it serves, and reviewed whenever that server is rebuilt.
Admins searching this area meet a policy named Specify SHA1 thumbprints of certificates representing trusted RDP publishers, under Remote Desktop Connection Client. Know it for what it is: it governs trust in signed .rdp files - connection files published by your servers - not the server certificate warning this guide set is about. It belongs to the published-apps world, where it stops prompts about who published a connection file. Setting it will not silence the certificate dialog for ordinary connections, and confusing the two has wasted many admin hours. It is a good policy in its own lane; it is simply not this lane.
Every fleet discussion eventually surfaces the lazy option: one policy that softens certificate warnings for all connections, everywhere, permanently. Resist it in writing if you have to. You would be removing the identity check from every future connection your users make - including connections you do not know about yet, to servers you do not own. The per-server trust routes above exist precisely so that no admin ever needs the blanket one.
A final fleet habit, whatever route you choose: document each trusted server, its thumbprint and its renewal date in one short register. Fleets do not suffer from popups; they suffer from nobody remembering which fingerprints were verified, and when. The register is what turns a rebuild morning from detective work back into routine.
The full one minute fix, shown live on a real Windows 11 PC, step by step.
Watch Full VideoYes - it deploys exactly the trust the checkbox creates, with the fingerprint verified once by you instead of once per user. Its costs are bookkeeping: keep the fingerprint current when server certificates change, and keep the policy scoped to named servers. For a small fleet that trade is entirely reasonable.
Policy can govern Remote Desktop client behaviour centrally, and managed fleets commonly restrict saving credentials and exceptions on shared machines. What matters more is the culture the policy backs: users who know an unexpected popup means stop and call IT will protect you better than any single setting.
Not as designed - auto-enrolment and CA trust distribution ride on domain membership. Workgroup machines fall back to the per-server trust routes: the checkbox, the REG pin, or a policy preference from whatever management tool does reach them.