Troubleshooting PowerShell Script Execution Failures in User Context with Ivanti Application Control and ControlUp

A user encountered an issue when attempting to run PowerShell scripts on endpoint machines using ControlUp (CU) in the user context. While executing scripts in the system context was successful, running them as the user failed with an error code -1. The environment included Ivanti Application Control, a security solution similar to Windows Defender Application Control (WDAC) or AppLocker, which enforces application execution policies. The user had configured a process rule allowing SipAgent.exe to launch PowerShell.exe, which was confirmed to function correctly via Process Monitor and Process Explorer, as PowerShell.exe briefly appeared. However, the actual PowerShell script never executed, even a simple command like ‘Start-Sleep 1000’ failed to run.

Disabling the Ivanti Application Control service restored the ability to run scripts, indicating a conflict with the security controls. Interestingly, no block events were logged by Ivanti, suggesting the issue was not a straightforward deny event at the application control layer. The user inquired about which processes and system files ControlUp uses during script execution to better understand the interaction.

The root cause was identified as an Ivanti configuration rule that elevated PowerShell processes for the test user account. This elevation interfered with the ControlUp execution mechanism, preventing the script from running properly in user context. The resolution involved creating an exception within the Ivanti elevation rule: PowerShell processes launched with the ‘-file’ parameter were excluded from elevation. This adjustment allowed the scripts to run successfully while maintaining the intended elevation policy for other PowerShell instances.

This case highlights the importance of carefully managing application control and elevation policies in security products like Ivanti when deploying user-context scripts via ControlUp. Explicitly excluding ControlUp-launched PowerShell processes that run script files from elevation can prevent execution failures without compromising security. Users facing similar issues should review their application control and elevation configurations, particularly any rules that modify or elevate PowerShell, and test exclusions for script execution parameters. For more details on ControlUp’s script execution methods and related settings, users can consult the official ControlUp documentation at https://docs.controlup.com.

Read the entire ‘Troubleshooting PowerShell Script Execution Failures in User Context with Ivanti Application Control and ControlUp’ thread below:

Hi,

I am unable to send PowerShell scripts to machines in the user context. System context is working fine.

We are using Ivanti Application Control (similar to WDAC/AppLocker).

We have created a process rule: SipAgent.exe is allowed to execute PowerShell.exe. We see this is working fine, with procmon. The process is created. Process Explorer does shows PowerShell.exe for a few milliseconds.

For some reason, the script itself is not executing. Error -1. Even a simple ‘Start-Sleep 1000’ is not working.

When we disable the Ivanti Application Control service, all is working well.

I don’t see any block events in Ivanti.

What kind of processes and system files are using for this CU feature?

Thnx!

hmmm any idea?

The problem is solved! In Ivanti I had a configuration which elevated the PowerShell process for my test account. Because of this, CU was unable to execute the script for some reason.

I have created an exception on this elevation rule. Every PS process created with the -file parameter will be excluded from elevation.

Problem solved!

Continue reading and comment on the thread ‘Troubleshooting PowerShell Script Execution Failures in User Context with Ivanti Application Control and ControlUp’.  Not a member? Join Here!