How to Let a Standard Domain User Run One Program as Administrator Without Giving Admin Rights

In many corporate environments, users work under standard domain accounts without local administrator privileges. This is a fundamental security practice known as the principle of least privilege.

However, system administrators frequently encounter a practical problem:
some applications require administrator rights to run, even though users only need access to that specific application.

This situation is common with:

• legacy enterprise software
• engineering tools
• security camera management software
• poorly designed applications that attempt to write to protected locations such as Program Files or HKLM registry keys

Granting full local administrator rights to users is usually unacceptable because it allows them to:

• install unauthorized software
• bypass security controls
• modify system settings
• potentially compromise the workstation

Because of this, administrators often need a controlled way to allow a standard user to run a specific application with elevated privileges, without giving the user general administrator rights.

To better understand how professionals solve this problem in real environments, I started a discussion with system administrators in the sysadmin community and collected the most common approaches used in practice.

The original discussion can be found here:

How do you let a standard domain user run one specific app as admin?
byu/Winter_Engineer2163 insysadmin

Based on that discussion, additional technical analysis, and my own experience solving similar problems in real Windows environments, this article explores the main architectural approaches used to address this challenge.

Each method is explained with practical examples, implementation steps, and a discussion of its security implications.

Why Some Applications Require Administrator Rights

Before looking at the different ways to allow a standard user to run an application with elevated privileges, it is important to understand why some applications require administrator rights in the first place.

In many cases, the application does not actually need full administrative privileges. Instead, it attempts to access system resources that are protected by default in Windows.

The most common causes include the following.

Writing to Program Files

Standard users do not have write permissions to the Program Files directory.

Some legacy applications try to store configuration files, logs, or temporary data inside their installation directory, for example:

C:\Program Files\Vendor\App\config.ini

When a standard user runs the application, Windows blocks the write operation, which causes the application to fail unless it is started with administrative privileges.

Writing to HKLM Registry Keys

Another common issue is writing to registry keys under:

HKEY_LOCAL_MACHINE

Standard users typically have read-only access to most locations under HKLM.
If the application attempts to create or modify values there, it will fail without elevation.

Example:

HKLM\Software\Vendor\App

Older applications often store configuration data here instead of using user-level locations like HKCU.

Accessing Protected System Resources

Some applications attempt to access resources that require administrative privileges, such as:

• device drivers
• low-level hardware interfaces
• protected system folders
• system services

In these cases, elevation may actually be required for the application to function correctly.

Legacy Application Design

Many enterprise environments still rely on legacy software that was originally developed for older versions of Windows, when users commonly operated with administrative privileges.

These applications were never designed with modern security models in mind and may assume that the user has full system access.

Because of this, they often fail when executed under a standard user account.

Understanding the root cause is important because in many situations the problem can be solved by fixing the underlying permission issue, rather than granting administrative privileges to the user.

Approach 1: Fixing the Underlying Permission Problem (Recommended Approach)

In many cases, an application requires administrator privileges not because it truly needs them, but because it attempts to access system resources that are restricted for standard users.

Instead of elevating the application, a better approach is to identify the exact permission issue and grant the minimum required access.

This can often allow the application to run successfully under a standard user account.

A practical way to identify these issues is by using Process Monitor, a tool from Microsoft Sysinternals.

Step 1: Download and Launch Process Monitor

Download Process Monitor from the official Microsoft Sysinternals page:

https://learn.microsoft.com/en-us/sysinternals/downloads/procmon

Extract the downloaded archive. Inside the archive you will see several executables:

• Procmon.exe – 32-bit version
• Procmon64.exe – 64-bit version
• Procmon64a.exe – ARM64 version (for Windows on ARM devices)

On most modern Windows systems you should run:

Procmon64.exe

Right-click the executable and select Run as administrator.

When Process Monitor starts, it immediately begins capturing activity from all processes in the system. This can quickly generate a large number of events, so it is helpful to clear the initial capture before starting your test.

Press:

Ctrl + X

This clears all currently captured events so the log will only contain activity generated during your troubleshooting session.

You can also control event capturing using:

Ctrl + E – Start or stop event capture

This can be useful if you want to pause logging while preparing to reproduce the issue.

Step 2: Create a Filter for Access Denied Events

To demonstrate how permission issues can be diagnosed, we will reproduce a simple example using a small test command in PowerShell. The command will attempt to write a file inside the Program Files directory, which normally requires administrative privileges.

While the command runs, Process Monitor will capture the system calls made by the process. We will then analyze the recorded events to identify the exact permission that is missing.

Before running the test, it is helpful to configure a filter in Process Monitor so that only relevant errors appear in the log.

By default, Process Monitor records all system activity, which can generate thousands of events in just a few seconds. To focus on permission issues, it is helpful to filter the results.

Open the filter menu:

Filter → Filter…

Add the following rule:

Result | is | ACCESS DENIED | Include

Click Add, then OK.

Process Monitor will now display only operations where Windows returned ACCESS DENIED.

If the log still contains too many events, you can further reduce noise by filtering for the process that will run the test:

Process Name | is | powershell.exe | Include

This ensures that the log shows only permission errors generated by the test command.

In the next step, we will run the PowerShell command that reproduces the permission problem and observe how it appears in Process Monitor.

Step 3: Reproduce the Permission Problem

To demonstrate the troubleshooting process, we will reproduce a simple permission error.

Create the following directory:

C:\Program Files\TestApp

You do not need to create the config.txt file manually. The test command will attempt to create and write to this file.

Next, open PowerShell as a standard user and run:

Add-Content "C:\Program Files\TestApp\config.txt" "test"

This command attempts to append text to the file config.txt. If the file does not exist, PowerShell will try to create it.

However, standard users do not have write permissions inside Program Files, so the operation fails with an error similar to:

PS C:\Users\simpleUser> Add-Content "C:\Program Files\TestApp\config.txt" "test"
Add-Content : Access to the path 'C:\Program Files\TestApp\config.txt' is denied.
At line:1 char:1
+ Add-Content "C:\Program Files\TestApp\config.txt" "test"
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : PermissionDenied: (C:\Program Files\TestApp\config.txt:String) [Add-Content], UnauthorizedAccessException
    + FullyQualifiedErrorId : GetContentWriterUnauthorizedAccessError,Microsoft.PowerShell.Commands.AddContentCommand

While this command runs, Process Monitor captures the underlying system activity, which we will analyze in the next step.

Step 4: Locate the Failing Operation

Return to Process Monitor and examine the captured events.

You should see entries similar to the following:

Operation:

CreateFile

Path:

C:\Program Files\TestApp\config.txt

Result:

ACCESS DENIED

Detail:

Desired Access: Generic Write

Even though the command was executed only once, multiple ACCESS DENIED entries may appear. This is normal. Applications often attempt to access the same resource several times using different access modes.

The key observation is that the same path appears repeatedly, which reveals the resource causing the failure.

Step 5: Understand the Event Details

From the captured event we can determine exactly what happened.

The Operation column shows:

CreateFile

In the Windows API, this function is used both for creating new files and opening existing files.

The Path column shows the resource the process attempted to access:

C:\Program Files\TestApp\config.txt

Finally, the Detail column reveals the requested permission:

Desired Access: Generic Write

This indicates that the process attempted to open the file with write access.

Because the file is located inside Program Files, Windows denies the operation for standard users.

Step 6: Filtering Noise in Process Monitor

Even after applying filters, the log may still contain a large number of events.

To simplify analysis, you can reduce noise using several built-in features in Process Monitor.

First, enable the option:

Filter → Drop Filtered Events

When this option is enabled, Process Monitor will stop recording events that do not match the filter, which significantly reduces memory usage and makes the log easier to read.

You can also reset the capture before running your test:

Ctrl + X – Clear events
Ctrl + E – Start capture

Then reproduce the issue again.

This ensures that the log contains only the events generated during the test scenario.

Step 7: Using File Summary to Quickly Identify Problems

Another powerful feature in Process Monitor is the File Summary view.

Open it from the menu:

Tools → File Summary

This view aggregates file system activity and shows which files were accessed by the captured processes.

In many cases, the problematic file will appear with a high number of ACCESS DENIED results, making it easy to identify the source of the problem without manually scanning thousands of events.

You can also double-click on a file name in this list.
This will automatically navigate you to the corresponding events in the main Process Monitor window, showing which process accessed the file and what operation was performed.

This makes it much faster to identify the exact process responsible for the issue.

This feature is particularly useful when troubleshooting large applications that access many files during startup.

Additional Useful Filters

In addition to filtering for ACCESS DENIED events, Process Monitor provides several other filters that can help identify common application issues and improve troubleshooting efficiency.

Using these filters allows you to quickly narrow down the trace and focus on relevant events.

NAME NOT FOUND

The NAME NOT FOUND result indicates that the application attempted to access a file, directory, or registry key that does not exist.

Example filter:

Result is NAME NOT FOUND

This filter helps identify:

• missing files
• incorrect file paths
• missing registry keys
• incomplete application installations

It is especially useful when diagnosing configuration or dependency issues.

PATH NOT FOUND

The PATH NOT FOUND result occurs when the application tries to access a directory that does not exist.

Example filter:

Result is PATH NOT FOUND

This filter can help detect:

• incorrect directory paths
• missing application folders
• installation problems

Such issues often occur when software expects a directory structure that has not been created.

BUFFER OVERFLOW

The BUFFER OVERFLOW result in Process Monitor usually indicates that the buffer provided by the application was too small to hold the returned data.

Example filter:

Result is BUFFER OVERFLOW

In many cases, this is normal behavior, because the application may retry the operation with a larger buffer.

However, frequent occurrences may indicate inefficient or problematic application behavior.

SHARING VIOLATION

The SHARING VIOLATION result indicates that a file is currently in use by another process.

Example filter:

Result is SHARING VIOLATION

This filter helps identify:

• file locking conflicts
• multiple processes accessing the same file
• applications that fail to release file handles

It is particularly useful when troubleshooting issues related to file access conflicts.

REPARSE

The REPARSE result appears when Windows redirects file access through a symbolic link, junction, or reparse point.

Example filter:

Result is REPARSE

This filter helps detect:

• symbolic link usage
• redirected file paths
• filesystem redirection scenarios

Understanding these events can clarify why an application accesses a different path than expected.

Using Analysis Results to Enable Application Execution

After analyzing the application behavior with Process Monitor, the collected information can be used to determine which specific resources require elevated access.

In many cases, applications request administrative privileges not because they need full system control, but because they attempt to access specific protected resources.

By identifying these resources, it may be possible to resolve the issue without granting full administrative rights to the user.

Typical resources that may require additional permissions include:

• specific files or directories
• registry keys
• configuration files
• application data folders

Once the required resources are identified, permissions can be adjusted so that the application can access them while the user continues operating under standard user privileges.

This approach helps maintain system security while allowing the application to function correctly.

Identifying Required Resources

During analysis in Process Monitor, special attention should be given to events where the application attempts to access restricted resources.

Common indicators include:

• attempts to access protected system directories
• attempts to modify configuration files
• attempts to write to restricted registry keys

These events reveal exactly which resources the application expects to modify or access.

Once identified, these resources can be reviewed and appropriate permissions may be granted where necessary.

Applying Targeted Permission Changes

Instead of granting full administrative privileges, permissions can often be modified only for the specific resources required by the application.

Examples include:

• granting write access to a specific application folder
• allowing access to a particular registry key
• modifying permissions for configuration files

This targeted approach allows the application to run successfully while maintaining principle of least privilege.

Approach 2: Running Applications with Administrative Privileges Using Task Scheduler

Another method for running an application with elevated privileges without granting administrative rights to the user is by using Windows Task Scheduler.

This approach allows an administrator to create a scheduled task that runs with administrative permissions, while the user can start the task without having administrator rights.

How the Method Works

In this approach:

• an administrator creates a scheduled task
• the task is configured to run with elevated privileges
• the user launches the task instead of running the application directly

When the task starts, the application runs using the permissions defined in the task configuration.

This allows the application to perform operations that normally require administrative privileges, while the user account itself remains a standard user.

Creating the Scheduled Task

To configure this method:

1. Open Windows Task Scheduler
2. Select Create Task
3. Configure the following options:

General Tab

On the General tab configure the following settings:

Name

Specify a task name that will be used to run the task.

Example:

oldapp

This name will later be used in the command that starts the task.

Description

Optionally add a description explaining the purpose of the task.

Example:

run old camera software as admin

This is useful for documentation and administration.

User Account

Specify the account that will run the task.

Typically this should be an administrator account, since the task will execute the application with elevated privileges.

Run with highest privileges

Enable this option.

This ensures the application will run with administrative privileges.

Hidden

Optionally enable Hidden if you do not want the task to appear in the standard task list for users.

This can help prevent accidental modifications.

Configure for

Select the operating system version used in the environment.

Example:

Windows 10

Configuring the Action

After configuring the General tab, open the Actions tab in Windows Task Scheduler.

1. Open the Actions tab
2. Click New

This opens the New Action configuration window.

Action Type

In the Action dropdown menu select:

Start a program

This option allows the task to launch an executable application.

Program / Script

In the Program/script field specify the path to the application executable.

Example:

"C:\Program Files\iVMS-4200 Station\iVMS-4200\iVMS-4200.exe"

You can either type the path manually or click Browse to locate the executable file.

This is the program that will run with administrative privileges when the task is triggered.

Add Arguments (Optional)

If the application supports command-line parameters, they can be specified here.

Example:

--config config.txt

This field can remain empty if the application does not require additional parameters.

Start In (Recommended for Legacy Applications)

The Start in field defines the working directory for the application.

Example:

C:\Program Files\iVMS-4200 Station\iVMS-4200

Although this field is optional, it is recommended to configure it when working with legacy applications such as iVMS-4200.

Some older applications expect configuration files, plugins, or DLL libraries to be located relative to the working directory. If the working directory is not defined, the application may fail to locate required resources.

Specifying the correct Start in directory helps prevent issues where the application cannot find:

• configuration files
• plugin directories
• dependent DLL libraries

Save the Action

After configuring the fields:

1. Click OK
2. The new action will appear in the Actions list of the task.

Once the task is saved, the scheduled task will launch the specified application with administrative privileges.

How Users Launch the Application

After the task has been created and configured, users do not run the application directly.
Instead, they launch the scheduled task, which starts the application with administrative privileges.

This approach allows the application to run with elevated permissions while the user account remains a standard user.

Running the Task from the Command Line

The scheduled task can be started using the Windows command line utility schtasks.

Example:

schtasks /run /tn "oldapp"

Explanation:

• /run starts the task
• /tn specifies the task name

In this example, oldapp is the name defined earlier when creating the task in Windows Task Scheduler.

When this command is executed, Windows launches the scheduled task, which in turn starts the application with administrative privileges.

Creating a Shortcut for Users

To make the process easier for users, administrators can create a desktop shortcut that runs the scheduled task.

1. Right-click on the desktop
2. Select New → Shortcut

In the location field, enter the following command:

schtasks /run /tn "oldapp"

3. Click Next
4. Provide a shortcut name, for example:

Old Camera Software

5. Click Finish

Now users can simply double-click the shortcut to launch the application.

Changing the Shortcut Icon (Optional)

To make the shortcut look like the original application:

1. Right-click the shortcut
2. Select Properties
3. Click Change Icon
4. Select the icon from the original executable file

Example executable:

C:\Program Files\iVMS-4200 Station\iVMS-4200\iVMS-4200.exe

This makes the shortcut appear identical to the original application while still launching the scheduled task in Windows Task Scheduler.

Security Considerations

When using Windows Task Scheduler to run applications with administrative privileges, it is important to understand the security implications of this method.

Although users do not receive administrator rights, the scheduled task still executes the application with elevated privileges.

For this reason, administrators should carefully control which applications are configured to run in this way.

Limit Access to Trusted Applications

Only trusted and verified applications should be configured to run with elevated privileges.

If an untrusted application is launched through a scheduled task configured with administrative permissions, it may gain the ability to perform privileged operations on the system.

Restrict Who Can Run the Task

Access to the scheduled task should be limited to the users who actually need to run the application.

This helps prevent unauthorized use of the elevated task.

Administrators can manage task permissions directly in Windows Task Scheduler to control which users are allowed to execute the task.

Protect the Application Directory

Ensure that standard users cannot modify files in the application directory.

If users are able to replace or modify the executable file that the scheduled task runs, they could potentially execute arbitrary code with administrative privileges.

For this reason, directories such as:

C:\Program Files\

should remain writable only by administrators.

Avoid Using This Method for High-Risk Applications

This approach should not be used for applications that process untrusted input or execute external scripts.

Such applications may expose the system to privilege escalation risks if they run with elevated permissions.

Approach 3: Fixing Legacy Applications Using Compatibility Shims

Another practical approach for running legacy applications without granting administrative privileges is using application compatibility layers and shims.

These tools are available through Microsoft Compatibility Administrator, which is included in the Windows Assessment and Deployment Kit (Windows ADK).

Compatibility layers and fixes allow administrators to modify how an application interacts with Windows without modifying the application itself.

Instead of changing the executable file, the compatibility engine intercepts certain Windows API calls and adjusts the system response so the application can run correctly.

This method is widely used when:

• legacy software expects administrative privileges
• applications were designed for older Windows versions
• the vendor no longer maintains the software

Installing Compatibility Administrator

To create compatibility fixes, administrators must install the Application Compatibility Tools component from Windows Assessment and Deployment Kit.

Steps:

1. Download the Windows Assessment and Deployment Kit from Microsoft(https://learn.microsoft.com/en-us/windows-hardware/get-started/adk-install).
2. Launch the installer.
3. During installation select the component:

Application Compatibility Tools

After installation, the following tools will appear in the Start menu:

• Microsoft Compatibility Administrator (32-bit)
• Microsoft Compatibility Administrator (64-bit)

Administrators should launch the version that matches the architecture of the application they are troubleshooting.

Creating an Application Compatibility Fix

To create a compatibility configuration:

1. Open Microsoft Compatibility Administrator
2. Select New Database → Application Fix
3. Enter the application name
4. Select the executable file

The wizard then allows administrators to configure:

• Compatibility Modes
• Compatibility Fixes

These options solve different types of legacy application issues.

Using Compatibility Modes to Emulate Older Windows Versions

Many legacy applications fail because they perform strict checks against the Windows version.

To resolve this, administrators can apply a Compatibility Mode that makes the application behave as if it is running on an older version of Windows.

In Microsoft Compatibility Administrator, this option appears as:

Run this program in compatibility mode for:

Examples include:

Windows XP
Windows Vista
Windows 7
Windows 8

When a compatibility mode is selected, Windows internally applies multiple compatibility layers that adjust system responses for the application.

Example Scenario

A legacy installer checks the operating system version and refuses to run on Windows 10 or Windows 11.

Applying Windows XP compatibility mode allows the installer to proceed because the system reports behavior compatible with Windows XP.

Using RunAsInvoker to Bypass Administrator Requirement

One of the most commonly used compatibility fixes is RunAsInvoker.

This fix forces the application to run with the same privileges as the user who launches it.

It prevents the application from requesting elevation through UAC.

This approach is frequently used when legacy software unnecessarily requires administrative privileges.

A full step-by-step guide explaining how to configure this fix is available in the following article:

Run Legacy Applications Without UAC Prompt Using RunAsInvoker

That article demonstrates how to configure RunAsInvoker using Microsoft Compatibility Administrator.

Additional Compatibility Fixes Used in Practice

In addition to compatibility modes, administrators can apply individual compatibility fixes to address specific problems.

Below are several fixes that are frequently used when troubleshooting legacy software.

CorrectFilePaths: Redirecting Hardcoded File Locations

Some legacy applications attempt to write files to protected directories such as:

C:\Program Files
C:\Windows

Standard users cannot write to these locations.

The CorrectFilePaths compatibility fix allows administrators to redirect file operations to a different location where users have write permissions.

Example Scenario

An application tries to create a configuration file in:

C:\Program Files\LegacyApp\config.ini

Using CorrectFilePaths, the file can be redirected to:

C:\Users\Public\LegacyApp\config.ini

This allows the application to run without administrative privileges.

VirtualRegistry: Redirecting Registry Writes

Many legacy applications attempt to write configuration data to protected registry locations such as:

HKLM\Software

Standard users cannot modify these keys.

The VirtualRegistry compatibility fix redirects these registry writes to a location within the user’s registry hive.

This allows the application to store settings without requiring administrative permissions.

ForceAdminAccess: Bypassing Administrator Checks

Some legacy applications perform internal checks to verify whether the current user belongs to the Administrators group.

Even when elevated privileges are not actually required, these checks may prevent the application from starting.

The ForceAdminAccess compatibility fix modifies the result of these checks so that the application believes it is running with administrative privileges.

Combining Multiple Compatibility Fixes

In many real-world scenarios administrators combine several compatibility settings.

For example:

Compatibility Mode: Windows 7
RunAsInvoker
ForceAdminAccess

Using multiple compatibility fixes allows administrators to resolve several issues simultaneously.

Compatibility databases created in Microsoft Compatibility Administrator can then be deployed to systems where the legacy application is used.

Configuring Application Matching Information

Before completing the wizard, Microsoft Compatibility Administrator asks how the application should be identified on the system.

This step defines matching attributes that Windows will use to determine when the compatibility fixes should be applied.

Typical attributes include:

File Version
Product Name
Company Name
Checksum
File Size
Link Date

These properties are extracted directly from the executable file.

Recommended Approach

In most cases, the default selections generated by the tool are sufficient.

Administrators typically leave the automatically selected attributes unchanged, as they provide reliable identification of the application.

If necessary, additional attributes can be selected to make the match more specific.

Example

When the application iVMS-4200.exe is launched, Windows compares its properties against the matching information stored in the compatibility database.
If the attributes match, the configured compatibility fixes are automatically applied.

After confirming the matching criteria, click Finish to create the compatibility fix entry.

Installing the Compatibility Fix on a System

After selecting the required compatibility modes and fixes in Microsoft Compatibility Administrator, the next step is to save and install the compatibility database so that Windows can apply the configuration to the target application.

Compatibility fixes are stored in a database file with the .sdb extension.

Saving the Compatibility Database

After completing the Application Fix wizard:

1. Click Finish
2. The new fix will appear inside your custom database.
3. Save the database by selecting:

File → Save

Choose a name for the database, for example:

LegacyAppsFix.sdb

The database file will be saved locally and can be deployed to other systems if needed.

Installing the Fix Using Compatibility Administrator

The easiest way to apply the fix on the local system is directly from Microsoft Compatibility Administrator.

Steps:

1. In the left panel, select your custom database.
2. Right-click the database name.
3. Select:

Install

Windows will register the compatibility database and immediately apply the fixes to the target application.

When This Method Is Useful

Installing compatibility fixes using .sdb databases is particularly useful when:

• legacy applications require small behavioral adjustments
• software incorrectly requires administrator privileges
• applications perform outdated OS compatibility checks

Using compatibility databases allows administrators to solve these issues without modifying the application or changing system security policies.

Approach 4: Running Legacy Applications Using Virtualization

In some cases, legacy applications cannot be reliably fixed using compatibility layers or privilege workarounds. This usually occurs when the application depends on outdated libraries, drivers, or system components that are no longer supported on modern versions of Windows.

In these situations, administrators often run the application inside a virtual machine.

Virtualization allows administrators to create an isolated environment that replicates the operating system originally required by the legacy software.

Modern Windows systems support virtualization through several platforms, including:

• Microsoft Hyper-V
• Oracle VirtualBox
• VMware Workstation

Using virtualization, administrators can deploy an older operating system inside the virtual machine, for example:

Windows XP
Windows 7
Windows Server 2008

The legacy application can then run inside that environment without being affected by compatibility issues present on modern systems.

When Virtualization Is the Best Solution

Virtualization is particularly useful when:

• the application depends on obsolete Windows components
• legacy drivers are required
• the software performs strict operating system validation checks
• compatibility shims do not resolve the issue

Because the application runs inside an isolated system, the host operating system remains unaffected.

Advantages of the Virtualization Approach

Using virtualization provides several advantages:

• full compatibility with the original operating system environment
• isolation from the host system
• ability to preserve legacy environments for long-term use
• simplified troubleshooting

This approach is widely used in enterprise environments where legacy software must remain operational even after operating system upgrades.

Limitations of Virtualization

While virtualization is a powerful solution, it also introduces some operational overhead.

Administrators must maintain the virtual machine, including:

• operating system updates
• backups
• storage allocation

Additionally, running applications inside a virtual machine may introduce minor performance overhead depending on the virtualization platform and available hardware resources.

Approach 5: Running Legacy Applications Using RemoteApp

Another enterprise approach for running legacy applications is publishing them through Microsoft RemoteApp, a component of Microsoft Remote Desktop Services.

In this model the application is installed and executed on a centralized Remote Desktop server rather than on individual workstations.

Administrators publish the application as a RemoteApp program, allowing users to launch it remotely while the execution occurs on the server.

Users typically access the application through:

• an RDP shortcut
• a RemoteApp feed
• a Remote Desktop web portal

Because the application runs on the server, compatibility requirements, administrator privileges, and legacy dependencies are handled within the controlled server environment instead of on user workstations.

This approach is commonly used in enterprise environments where legacy applications must remain operational while workstation operating systems continue to be updated.

Approach 6: Using Enterprise Privilege Management Solutions

In enterprise environments, legacy applications that require administrative privileges are often handled using privileged access management (PAM) or endpoint privilege management (EPM) platforms.

These systems allow administrators to elevate specific applications without granting users full local administrator rights.

Instead of modifying the application itself, administrators define centralized policies that automatically allow approved executables to run with elevated privileges.

Typical capabilities include:

• application allowlisting
• controlled privilege elevation
• centralized policy management
• auditing and logging of privileged actions

Several enterprise platforms provide this functionality, including:

• Microsoft Intune Endpoint Privilege Management
• CyberArk Endpoint Privilege Manager
• BeyondTrust Privilege Management
• Delinea Privilege Manager
• Ivanti Endpoint Manager
• ManageEngine Endpoint Central
• Heimdal Privileged Access Management
• AdminByRequest
• ThreatLocker
• AutoElevate

Using these systems, administrators can define policies that allow trusted legacy applications to run with elevated privileges while keeping users as standard accounts.

This approach is commonly used in organizations where strict least privilege policies must be enforced while still supporting legacy software.