When using PsExec to remotely execute tasks that require elevated privileges on Windows systems (particularly Server 2008 R2, Windows 7, and similar versions), administrators frequently encounter UAC-related roadblocks. The User Account Control mechanism intercepts elevation requests, causing installations to stall and administrative tasks to fail with "Access Denied" errors.

PsExec's default behavior doesn't automatically handle UAC prompts because:

• UAC prompts are interactive and require desktop access
• Remote sessions typically lack the necessary UI context
• The SYSTEM account (often used by PsExec) has different privileges than an elevated admin

Here are several approaches to overcome UAC when using PsExec:

Method 1: Scheduled Tasks with Highest Privileges

Create a scheduled task that runs with highest privileges, then trigger it via PsExec:

schtasks /create /tn "ElevatedTask" /tr "C:\installer.exe" /sc ONCE /st 00:00 /ru SYSTEM /rl HIGHEST
psexec \\target-computer schtasks /run /tn "ElevatedTask"

Method 2: Using the -h Flag

PsExec's -h flag attempts to run with the account's elevated token:

psexec \\target-computer -u adminuser -p password -h "C:\installer.exe"

Method 3: WMI Invocation

Combine PsExec with Windows Management Instrumentation for elevation:

wmic /node:target-computer process call create "cmd.exe /c start C:\installer.exe"

Create a script that handles its own elevation, then call it via PsExec:

@echo off
:: Check for admin rights
NET SESSION >nul 2>&1
IF %ERRORLEVEL% NEQ 0 (
    echo Requesting elevation...
    powershell -Command "Start-Process cmd -ArgumentList '/c %~s0' -Verb RunAs"
    exit /b
)

:: Your elevated code here
"C:\installer.exe"

While these methods bypass UAC, they introduce security implications:

• Credentials may be exposed in command history
• Elevated processes have broader system access
• Audit trails become more complex

Always consider whether UAC bypass is truly necessary for your specific task.

For enterprise environments, consider:

• Group Policy Software Installation
• Configuration Management tools (SCCM, Ansible, Puppet)
• Windows Remote Management (WinRM)

These solutions provide more controlled elevation mechanisms than direct UAC bypass.

---

When managing Windows Server 2008 R2 systems remotely, User Account Control (UAC) presents a significant hurdle for automation tasks - particularly software installations that require elevation. The traditional PsExec approach fails because the UAC prompt can't be interacted with remotely, leaving processes stuck in limbo.

Windows security architecture operates on several privilege levels:

Standard User → Administrator → SYSTEM → TrustedInstaller

Most installation packages require at least Administrator-level privileges with UAC consent.

Here are three effective approaches to handle elevated tasks remotely:

1. Scheduled Task Method

Create a task that runs with highest privileges:

schtasks /create /s \\targetserver /tn "ElevatedInstall" /tr "C:\installer.exe" /ru SYSTEM /rl HIGHEST /sc ONCE /st 00:00
schtasks /run /s \\targetserver /tn "ElevatedInstall"

2. Service-Based Execution

Create a temporary service for privilege escalation:

sc \\targetserver create ElevatedInstaller binPath= "cmd /c start C:\installer.exe" type= own type= interact
sc \\targetserver start ElevatedInstaller

3. Remote Registry + RunOnce

For package installations that can run silently:

reg add \\targetserver\HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce /v InstallTask /t REG_SZ /d "C:\installer.exe /quiet /norestart" /f

Combine these PsExec parameters for best results:

-h - Run with elevated token if UAC is enabled

-i - Interactive session (required for some installers)

-s - Run as SYSTEM account

Example for an interactive elevated install:

psexec \\server -u domain\admin -p password -i -h -d msiexec /i "\\fileserver\package.msi" /qn

While these methods bypass UAC prompts, they don't weaken security:

• Credentials are still protected (transmitted securely)
• UAC remains enabled for interactive sessions
• Audit trails are maintained in Event Logs

Error 5 (Access Denied): Typically means the credential delegation failed. Verify:

- The account has admin rights on target

- Network Level Authentication is enabled

- Windows Firewall allows remote administration