Jobs
Jobs are the history of scripts that have been run.
Jobs are the result of running a script. Jobs are retained based on the script and server level settings.
Jobs can be viewed by clicking the Automation / Jobs page. Click the View button to navigate to the job. Jobs in progress can also been cancelled.
Job Output
Standard PowerShell streams such as information, host, error, warning and verbose are shown within the output pane.
Standard Output
Storing large amounts of pipeline output can negatively affect performance. You can discard pipeline output by setting the Discard Pipeline setting on scripts.
Pipeline output for jobs is also stored within PowerShell Universal. Any object that is written to the pipeline is stored as CliXml and available for view within the Pipeline Output tab.
You can expand the tree view to see the objects and properties from the pipeline.
Pipeline Output
Any errors written to the error stream will be available on the Error tab within the job page.
Errors
Some jobs will require feedback. Any script that contains a
Read-Host call will wait until there is user interaction with that job. The job will be in a Waiting for Feedback state, and you can respond to that feedback by click the Response to Feedback button on the job page.
Waiting for Feedback
To accept a
SecureString with a password input field, you can use the -AsSecureString parameter of Read-Host.You can use
Invoke-PSUScript to invoke jobs from the command line. You will need a valid App Token to do so. Parameters are defined using dynamic parameters on the Invoke-PSUScript cmdlet.Invoke-PSUScript -Script 'Script1.ps1' -RequiredParameter 'Hello'
You can also call UA scripts from UA scripts. When running a job in UA, you don't need to define an app token or the computer name manually. These will be defined for you. You can just call
Invoke-PSUScript within your script to start another script. Both jobs will be shown in the UI. If you want to wait for the script to finish, use Wait-PSUJob.You can use the
Wait-PSUJob cmdlet to wait for a job to finish. Pipe the return value of Invoke-PSUScript to Wait-UAJob to wait for the job to complete. Wait-PSUJob will wait indefinitely unless the -Timeout parameter is specified.Invoke-PSUScript -Script 'Script1.ps1' -RequiredParameter 'Hello' | Wait-PSUJob
You can use the
Get-PSUJobPipelineOutput cmdlet to return the pipeline output that was produced by a job. This pipeline output will be deserialized objects that were written to the pipeline during the job. You can access this data from where you have access to the PowerShell Universal Management API.Get-PSUJobPipelineOutput -JobId 10
It may be required to return the output from a script's last job run. In order to do this, you will need to use a combination of cmdlets to retrieve the script, the last job's ID and then return the pipeline or host output.
$Job = Get-PSUScript -Name 'Script.ps1' | Get-PSUJob -OrderDirection Descending -First 1
Get-PSUJobPipelineOutput -Job $Job
Get-PSUJobOutput -Job $Job
The following example invokes a script, stores the job object in a
$job variable, waits for the job to complete and then returns the pipeline and host output.Invoke-PSUScript -Script 'Script1.ps1' -RequiredParameter 'Hello' | Tee-Object -Variable job | Wait-PSUJob
$Pipeline = Get-PSUJobPipelineOutput -Job $Job
$HostOutput = Get-PSUJobOutput -Job $Job
# Access the actual string returned by the job
# $HostOutput may be an array
$HostOutput.Data
If you are using PowerShell Universal 2.4 or later, you can use the
-Wait parameter of Invoke-PSUScript to achieve this.$Pipeline = Invoke-PSUScript -Script 'Script1.ps1' -RequiredParameter 'Hello' -Wait
The integrated mode allows calling these cmdlets from within PowerShell Universal without an App Token or Computer Name. It uses the internal RPC channel to communicate.
You can set the
-Integrated parameter to switch to integrated mode. This parameter does not work outside of PowerShell Universal.Invoke-PSUScript -Script 'Script.ps1' -Integrated
The following cmdlets support integrated mode.
- Get-PSUScript
- Invoke-PSUScript
- Get-PSUJob
- Get-PSUJobOutput
- Get-PSUJobPipelineOutput
- Get-PSUJobFeedback
- Set-PSUJobFeedback
- Wait-PSUJob
You can call jobs over REST using the management API for PowerShell Universal. You will need a valid app token to invoke jobs.
To call a script, you call an HTTP POST to the script endpoint with the ID of the script you wish to execute.
Invoke-RestMethod http://localhost:5000/api/v1/script/7 -Method POST -Body "" -Headers @{ Authorization = "Bearer appToken" } -ContentType 'application/json'
You can provide parameters to the job via a query string. Parameters will be provided to your script as strings.
$Parameters = @{
Uri = "http://localhost:5000/api/v1/script/path/PNP.ps1?Server=tester&Domain=test"
Method = "POST"
Headers = @{Authorization = "Bearer $Apptoken"}
ContentType = 'application/json'
Body = '{}'
}
Invoke-RestMethod @Parameters
You can set the environment by pass in the environment property to the job context. The property must be the name of an environment defined within your PSU instance.
$JobContext = @{
Environment = "PowerShell 7"
} | ConvertTo-Json
Invoke-RestMethod http://localhost:5000/api/v1/script/7 -Method POST -Body $JobContext -Headers @{ Authorization = "Bearer appToken" } -ContentType 'application/json'
You can set the run as account by passing in the name of a PSCredential variable to the Credential property.
$JobContext = @{
Credential = "MyUser"
} | ConvertTo-Json
Invoke-RestMethod http://localhost:5000/api/v1/script/7 -Method POST -Body $JobContext -Headers @{ Authorization = "Bearer appToken" } -ContentType 'application/json'
The default behavior for PowerShell Universal is to track jobs based on an autoincrementing int64-based ID. Every time a new job is run, the job is one higher in ID than the last. Because of this behavior, it is easy to guess other job IDs and can potentially lead to a security risk.
In order to avoid this issue, you can enable the
JobRunID experimental feature. Although internally the system still creates jobs with ascending numeric IDs, you cannot access jobs based on those IDs. Instead, a new field called RunID is used. RunID utilizes a GUID rather than an ID for look ups. This greatly reduces the ability for an attacker to guess a job ID.You will need to enable this feature to use it.
Set-PSUSetting -ExperimentalFeature ([PowerShellUniversal.ExperimentalFeatures]::JobRunId)
Last modified 2mo ago