Publishing custom PowerShell tools as RemoteApp presents a powerful yet surprisingly complex method for delivering lightweight utilities to end users across an organization. While the concept seems straightforward—package PowerShell scripts as easily accessible remote applications—the reality involves navigating a maze of technical hurdles that Microsoft's documentation often glosses over. The core challenge is fundamental: Remote Desktop Services (RDS) RemoteApp won't directly publish .PS1 files as applications. This limitation forces administrators to develop creative workarounds involving launcher executables, which then introduce their own cascading issues with execution policies, UNC path resolution, and DPI scaling mismatches between client and server environments.

The Fundamental Problem: PowerShell Scripts Aren't Executables

At its heart, the issue stems from how RemoteApp identifies and publishes applications. RemoteApp is designed to work with standard Windows executables (.exe files) or application shortcuts that point to such executables. PowerShell script files (.PS1) are not standalone executables; they require the PowerShell host (powershell.exe or pwsh.exe) to interpret and execute them. When you attempt to add a .PS1 file directly through the RemoteApp Manager interface, the system typically rejects it or fails to create a functional published application.

This architectural limitation necessitates what's commonly called the "launcher approach." Administrators must create a wrapper executable—often a simple batch file (.bat or .cmd) compiled to .exe, or a small compiled application—that serves as the published RemoteApp. This launcher's sole purpose is to invoke the PowerShell host with the appropriate parameters to run the target script. While this solves the immediate publishing problem, it opens several other technical challenges that must be addressed for a seamless user experience.

Creating Effective Launcher Solutions

The launcher serves as the bridge between RemoteApp's requirements and PowerShell's execution model. The most common approach involves creating a batch file with specific PowerShell invocation commands, then converting that batch file to an executable using tools like Bat To Exe Converter or Advanced BAT to EXE Converter. This conversion helps maintain a clean presentation (no flashing command window) and allows for icon customization that matches your corporate branding.

A typical launcher batch file contains commands like:

@echo off
powershell.exe -ExecutionPolicy Bypass -File "\\server\share\scripts\tool.ps1"
pause

After conversion to EXE, this becomes the application published through RemoteApp Manager. However, this basic implementation immediately encounters the first major hurdle: PowerShell execution policies. The -ExecutionPolicy Bypass parameter is crucial here, as it tells PowerShell to ignore the configured execution policy for this specific invocation. Without this parameter (or similar approaches like -ExecutionPolicy RemoteSigned), scripts may fail to run depending on the system's policy settings, which are often restricted in enterprise environments.

One of the most persistent issues when publishing PowerShell tools as RemoteApp involves Universal Naming Convention (UNC) path resolution. When a user launches a RemoteApp, they're essentially running an application within a remote desktop session on the RDS server. However, the script files themselves might be stored on a different file server—a common architecture for centralized script management.

This creates a double-hop authentication problem: the RDS server can access the file server, but the user's credentials don't automatically pass through to that second hop. When the launcher tries to execute \\fileserver\scripts\tool.ps1, it might fail with access denied errors, even though the same user could access that share directly from their physical desktop.

Several solutions exist for this UNC path challenge:

1. Storing Scripts Locally on RDS Servers:
The simplest approach involves copying PowerShell scripts directly to each RDS server in the farm. This eliminates UNC path issues entirely but creates maintenance overhead, as script updates must be deployed to multiple servers. This approach works best for small environments or scripts that rarely change.

2. Using Mapped Drives with Persistent Connections:
Configuring the RDS servers to have persistent mapped drives to the script repository can help, especially when combined with proper credential delegation. However, this approach can be fragile and may break during server reboots or network changes.

3. Implementing Credential Delegation with Kerberos:
The most robust enterprise solution involves configuring Kerberos constrained delegation. This allows the RDS server to delegate the user's credentials to the file server specifically for accessing the script share. While this requires Active Directory configuration and proper SPN setup, it provides seamless authentication without storing credentials.

4. Embedding Scripts Within Launchers:
For smaller scripts, some administrators embed the entire PowerShell code within the launcher executable itself. The launcher writes the script to a temporary location on the RDS server, executes it from there, then cleans up. This approach completely avoids UNC path issues but isn't practical for larger scripts or frequently updated tools.

The DPI Scaling Nightmare and Solutions

Perhaps the most visually disruptive issue when publishing PowerShell tools as RemoteApp involves DPI (dots per inch) scaling mismatches. This problem manifests when users with high-DPI displays (like 4K monitors) run RemoteApp sessions from servers with different DPI settings. PowerShell consoles and Windows Forms applications created with PowerShell can appear blurry, improperly sized, or with misaligned text and controls.

The root cause lies in how Remote Desktop handles DPI scaling between client and server. When the client device has a different DPI setting than the RDS server, applications can experience scaling artifacts. PowerShell is particularly vulnerable because:

  1. Console Host Issues: The classic PowerShell console (powershell.exe) has limited DPI awareness and often doesn't scale properly between different DPI environments.

  2. Windows Forms Applications: PowerShell scripts that create GUI elements using .NET Windows Forms are especially prone to DPI problems, as form controls may render at incorrect sizes.

  3. Remote Desktop Protocol Limitations: While newer versions of RDP have improved DPI virtualization, many enterprise environments run older configurations that exacerbate these issues.

Effective DPI Fixes for PowerShell RemoteApps:

Server-Side DPI Configuration:
Ensure your RDS servers are configured with appropriate DPI settings that match your most common client configurations. While this isn't always practical in environments with diverse client devices, establishing a standard (like 125% scaling) can reduce problems for the majority of users.

Application Manifest Modifications:
For compiled launcher executables, you can add an application manifest that declares DPI awareness. This tells Windows how the application should handle DPI scaling. The most effective setting for RemoteApp scenarios is often:

<application xmlns="urn:schemas-microsoft-com:asm.v3">
    <windowsSettings>
        <dpiAwareness>PerMonitorV2</dpiAwareness>
    </windowsSettings>
</application>

PowerShell 7 Advantages:
Microsoft's newer PowerShell 7 (based on .NET Core) generally handles DPI scaling better than Windows PowerShell 5.1. The cross-platform nature of PowerShell 7 means it was designed with varied display environments in mind. Migrating scripts to PowerShell 7 can significantly reduce DPI-related display issues in RemoteApp scenarios.

Client-Side RDP Settings:
Educate users to configure their RDP client settings appropriately. The "Display" tab in the Remote Desktop Connection client includes scaling options that can help. For the modern Remote Desktop client, enabling "Scale display to match this remote session" can improve the experience.

Execution Policy Considerations in Enterprise Environments

PowerShell's execution policy framework, while important for security, creates additional complexity when publishing tools as RemoteApp. Enterprise environments typically enforce restrictive execution policies (often AllSigned or RemoteSigned) to prevent unauthorized script execution. This conflicts with the need to run scripts from UNC paths or temporary locations.

The -ExecutionPolicy Bypass parameter in launchers provides one solution, but security teams may object to bypassing policies entirely. Alternative approaches include:

Digitally Signing Scripts:
Implementing a code signing certificate infrastructure allows scripts to be signed and trusted. When scripts are properly signed, they can run under AllSigned or RemoteSigned policies without modification. This represents the most secure enterprise approach but requires certificate management overhead.

Using Group Policy to Create Exceptions:
Windows Group Policy can configure execution policy exceptions for specific paths. Administrators can create policies that apply less restrictive policies to scripts in the corporate repository location while maintaining stricter policies elsewhere.

PowerShell Constrained Language Mode:
For scenarios where full language features aren't required, PowerShell's Constrained Language Mode can provide a middle ground. This mode restricts potentially dangerous language elements while allowing scripts to run. When combined with AppLocker or Windows Defender Application Control, it creates a robust security posture.

Deployment and Management Best Practices

Successfully implementing PowerShell tools as RemoteApp requires attention to deployment and management considerations beyond the technical hurdles:

Centralized Script Management:
Maintain scripts in a version-controlled repository with proper change management procedures. This becomes especially important when multiple RDS servers need access to the same script versions.

Launcher Versioning:
Implement a versioning scheme for your launcher executables. Include version information in the file properties or through a simple -Version parameter that displays when users run the tool with that flag.

Monitoring and Logging:
Build logging into your PowerShell scripts to track usage patterns and errors. Since these tools run in remote sessions, consider writing logs to a centralized location rather than local server disks.

User Education:
Prepare documentation that helps users understand how to access and use the published PowerShell tools. Include troubleshooting steps for common issues like authentication prompts or display problems.

Testing Across Client Variability:
Test your RemoteApp PowerShell tools across the range of client devices in your environment—different Windows versions, display resolutions, and network conditions. What works perfectly on a 1080p desktop might fail on a 4K laptop with 200% scaling.

The Future: PowerShell in Modern Remote Access Scenarios

As Microsoft continues evolving its remote access technologies, some alternatives to traditional RDS RemoteApp are emerging. Windows 365 Cloud PCs provide a different approach to application delivery, though they come with different cost and management considerations. Azure Virtual Desktop offers enhanced scaling and management capabilities that might simplify some of the challenges discussed here.

For organizations invested in traditional RDS, the techniques outlined remain essential. The combination of launcher executables with proper UNC path handling, DPI configuration, and execution policy management creates a workable solution for delivering PowerShell tools to end users. While the path isn't as straightforward as publishing standard Windows applications, the flexibility and power of making custom PowerShell tools available as easily accessible RemoteApps justify the implementation effort for many organizations.

Ultimately, publishing PowerShell tools as RemoteApp represents a classic IT challenge: bridging the gap between what users need and what technology directly supports. Through careful implementation of launchers, attention to authentication and pathing issues, and proactive management of display scaling, administrators can create robust solutions that extend PowerShell's capabilities throughout their organizations.