PSU 2026.3.4 – Permission denied when accessing script/job history from within a PSU App

PSU 2026.3.4 – Permission denied when accessing script/job history from within a PSU App

avatar
michaelhellebrandt

Hi,

I'm currently migrating an existing PowerShell Universal v4 dashboard to PSU v5 and running into permission issues when trying to access automation scripts and their job history from within a PSU App.

Environment

  • PowerShell Universal: 2026.3.4

  • App environment: Windows PowerShell 5.1

  • Authentication: Windows Authentication (Active Directory)

  • App roles: User, Administrator

  • App definition: Code

  • App URL: /ccms-admin

What I'm trying to achieve

In PSU v4, we used automation scripts to collect monitoring data from Exchange, SCOM, and DSC.

The dashboard periodically checked the latest completed and running PSU jobs. If the latest results were too old and no job was running, a new job was started.

The dashboard then displayed the pipeline output of the latest completed job.

This allowed multiple administrators to use the same dashboard without triggering redundant data collection jobs.

I'm trying to implement the same concept in PSU v5.

The problem

I created a simple test automation script:

New-PSUScript -Name 'CCMS-HomeProbe.ps1' `
    -Description 'Test job for monitoring data collection' `
    -Path 'Skripte\CCMS-HomeProbe.ps1'

The script runs successfully when executed manually from the PSU administration interface and produces the expected pipeline output.

However, when my PSU App tries to retrieve the script and its jobs using Get-PSUScript and Get-PSUJob, the request fails.

The current error is:

Test failed: Get-PSUScript failed:
Permission denied. The role specified does not have access to this resource.

The error occurs already at Get-PSUScript, so the subsequent Get-PSUJob and Get-PSUJobPipelineOutput calls are never reached.

The calls are made from a PowerShell function invoked by a New-UDDynamic component in the App.

What I've tried

  1. Verified that the automation script is registered in PSU and executes successfully when started manually.

  2. Verified that the App is configured with the User and Administrator roles.

  3. Configured explicit resource permissions using the new PSU permissions interface:

Identity | Resource | Access

Administrator | automation.scripts.Skripte/* | All

User | automation.scripts.Skripte/* | All

  1. Confirmed that the test script is located under Skripte\CCMS-HomeProbe.ps1, matching the configured resource path.

  2. Retested the App after changing these permissions.

Unfortunately, the error remains unchanged.

We also experimented with the PSU server cache in an earlier prototype, but encountered permission errors there as well. We therefore removed the cache entirely and switched to reading the job history directly. The current problem concerns access to automation scripts and their jobs.

Expected behavior

An authenticated administrator using the PSU App should be able to:

  • Retrieve an existing automation script.

  • Check its latest completed and running jobs.

  • Read the pipeline output of a completed job.

  • Start a new job when necessary, provided the user has the appropriate permissions.

This worked in our previous PSU v4 implementation.

Questions

  1. Is this a known issue with integrated PSU cmdlets in version 2026.3.4?

  2. Which resource permissions are required for an App to access automation scripts and job history?

  3. Are the permissions for reading job history different from those for managing or executing scripts?

  4. Is there a recommended way to implement this monitoring pattern in PSU v5 without granting unnecessarily broad permissions?

I'd prefer to keep using the native PSU cmdlets rather than implementing direct REST API calls or managing additional API tokens.

Any guidance would be appreciated.

Thanks!

Michael

All Comments (1)

avatar
Michel Audi

Hello Michael,

Thank you for the detailed description. The message does not name the refused permission, because PowerShell Universal returns that sentence for any permission check a cmdlet fails. Inside an App, with the default Strict security model, the cmdlets run with the permissions of the user who opened the App.

Is this a known issue in 2026.3.4? It depends on how the App calls Get-PSUScript, which the error does not show. Without a parameter or with -Id, it is checked against the global permission automation.scripts/read, which a folder permission such as automation.scripts.Skripte/* cannot satisfy, so that refusal is by design. With -Name and a backslash in the path, it can hit a known Windows issue in 2026.3.4 where a folder permission misses that path. The same issue affects starting a script that sits in a folder. Our development team has fixed it for an upcoming version, not published yet.

Each call has its own check.

1. Get-PSUScript -Name 'Skripte/CCMS-HomeProbe.ps1', with a forward slash, is checked against read on that path, which your folder permission covers.

2. Get-PSUJob -Script needs automation.jobs/read, which has no folder-scoped form and reads the history of every job.

3. Get-PSUJobPipelineOutput needs read on that job, covered by automation.jobs/read.

4. Invoke-PSUScript -Name needs read and execute on the script's path, and -Id needs the global automation.scripts/read.

So reading job history (automation.jobs) is separate from reading or starting scripts (automation.scripts).

For the shared pattern, I would run the collection script on a schedule and let the App only read its latest job and output. No visitor then starts a collection, so the dashboard role needs read on the script and automation.jobs/read, but no execute. If the collection script calls no PowerShell Universal cmdlets itself, the schedule needs no app token.

For on-demand starts on 2026.3.4, keep the probe script at the root of the Scripts list with read and execute on automation.scripts.CCMS-HomeProbe.ps1, and serialize the running-job check and the start across App sessions. The Integrated security model drops the user's context for every cmdlet, the broad option you want to avoid.

https://docs.devolutions.net/powershell-universal/config/module/#authorization-security-model

https://docs.devolutions.net/powershell-universal/security/enterprise-security/permissions/

Could you send me the exact Get-PSUScript line your App runs, and the result of Get-PSUScript -Name 'Skripte/CCMS-HomeProbe.ps1' in the App as the same user? Does that account also hold the built-in Administrator role in PowerShell Universal? That role carries every permission, so if it does and the call is still refused, I will look at that separately.

Best regards,

Michel

Michel Audi