Why the UAC "Yes" Button Disappears Over RDP — and How to Fix It

You click to install a tool or open an elevated console on your Windows VPS, a User Account Control (UAC) prompt appears over Remote Desktop — and the Yes button is nowhere to be found. Sometimes the dialog is half-rendered, sometimes only No is clickable, and sometimes the box is frozen behind the dimmed secure desktop. Until you can approve the prompt, every administrative action stalls.

This is almost always one of two problems: the account you are signed in with cannot elevate, or the UAC secure desktop is not drawing correctly across the RDP session. Both are fixable without touching the VPS console or opening a support ticket. Work through the checks below in order.

First, understand what you are seeing

A normal UAC prompt for an administrator shows Yes and No. A prompt for a standard user instead asks for an administrator's username and password — there is no Yes button by design, because a standard user cannot self-approve. If you expected a simple Yes/No box and got a credential form (or a greyed-out dialog), the account's privileges are the first thing to verify.

The other common symptom — a dialog that appears with missing or unclickable buttons — is a rendering fault. UAC switches to a protected secure desktop (the screen dims) before showing the prompt. Over RDP, that desktop switch occasionally fails to paint, leaving a prompt you can see but not use.

Check whether your account can actually elevate

Open a PowerShell window and confirm the signed-in account is a member of the local Administrators group:

Get-LocalGroupMember -Group 'Administrators'
whoami /groups | Select-String 'Administrators'

If your user is not listed, that explains the missing Yes button — Windows is offering the credential-prompt variant instead. Add the account to the group (from an already-elevated session, or using another admin's credentials):

Add-LocalGroupMember -Group 'Administrators' -Member 'youruser'

Sign out and back in so the new group membership is reflected in your token. On a VPS, log off the RDP session completely rather than just disconnecting, or the old token lingers.

Confirm UAC is configured sanely

The behaviour of the elevation prompt is driven by three values in the registry. Read them first — never change settings you have not inspected:

Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System' |
  Select-Object EnableLUA, ConsentPromptBehaviorAdmin, PromptOnSecureDesktop

• EnableLUA should be 1. With UAC switched off entirely, some installers and the elevation flow misbehave.
• ConsentPromptBehaviorAdmin controls what admins see. A value of 5 (prompt for consent for non-Windows binaries) is the normal, balanced setting. A value of 0 means admins elevate silently with no prompt at all — which can look like a "broken" dialog.
• PromptOnSecureDesktop is 1 when the dimmed secure desktop is used. This is the value most often responsible for the missing-button symptom over RDP.

The usual fix: turn off the secure desktop for RDP sessions

The secure desktop is a genuine security feature — it isolates the prompt from other processes. But its desktop switch is exactly what tends to glitch across a remote session, leaving an unclickable dialog. Disabling it makes UAC prompt on your ordinary desktop, where it renders reliably over RDP:

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System' -Name PromptOnSecureDesktop -Value 0

The change takes effect immediately for new prompts — no reboot needed. Trigger a fresh elevation (for example, launch an elevated PowerShell) to confirm the Yes button now appears and responds.

Weigh the trade-off: on a single-admin VPS this is a reasonable, low-risk change. If the server is shared or holds sensitive data, treat it as a temporary workaround — complete your task, then set the value back to 1. You can also reconnect to the stuck prompt by sending Ctrl+Alt+End (the RDP equivalent of Ctrl+Alt+Del) and choosing to return to the session, which sometimes forces the secure desktop to repaint without any registry change.

If the dialog is simply frozen

A prompt that paints with no working buttons can also be an Explorer or session rendering hiccup rather than a policy problem. Restarting the shell clears it in most cases:

Stop-Process -Name explorer -Force
Start-Process explorer

If even that leaves you locked out of the prompt, a clean reboot of the VPS resets the session stack. Where you have no working elevated path at all, use your hosting control panel's console or VNC view — that out-of-band screen is not bound by the RDP secure-desktop issue, so UAC prompts there behave normally and let you repair the account or registry.

Keep it from recurring

Once you are back in control, a few habits prevent a repeat:

1. Run administrative work from an elevated PowerShell opened once at the start of a session, rather than approving many individual prompts.
2. Keep each admin's account properly in the Administrators group so you get the Yes/No prompt, not the credential form.
3. Document any UAC registry change in your server notes, and restore PromptOnSecureDesktop to 1 if your security posture calls for it.
4. If the VPS is managed by Group Policy, remember that a domain or local policy can overwrite these values on refresh — set them in policy, not just the registry, so they stick.

In short: a missing Yes button is rarely a corrupted Windows install. It is the system telling you either that your account cannot elevate, or that the secure desktop did not render across RDP. Check the account, read the three UAC registry values, and toggle the secure desktop if the prompt still will not respond.