Table of Contents
Different cmdlet same error?
I get the error message Job suspended in Azure Automation with cmdlet Import-PSSession.
The solution I offer in this blog post may also be the solution for another cmdlet.
If this does not solve the problem for ‘Job was suspended’ , see if there is a connection with the Hybrid Worker.

Let’s fix: Job was suspended in Azure Automation
Your Import-PSSession or other cmdlet tries to send a stream larger than 1 MB to Azure Automation.
Because Azure Automation does not accept a stream larger than 1 MB it will fail and re-try the job. After 3 re-tries the job will be suspended. And show the below error:
Suspended
Job was suspended. For additional troubleshooting, check the Microsoft-SMA event logs on the computers in the Hybrid Runbook Worker Group that tried to run this job.
By streaming I mean the output sent to Azure Automation from your Hybrid Worker.
By out nulling you can prevent the stream to be send to Azure Automation. Microsoft has developed the Out-Null cmdlet especially for this.
Import-PSSession $Session | Out-Null
I personally am not a fan of Out-Null
. Out-Null
is generally a slower cmdlet compared to $null. If it’s for one cmdlet then it doesn’t really matter, but suppose you use a foreach
loop over 1000 iterations then the time can add up quickly.
I prefer $null then.$null
is used in the following way:
$null = Import-PSSession $Session
For more about Azure Automation Limits:
https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits#automation-limits
Hopefully your suspended jobs in Azure Automation will run now!
Let’s go through the additional troubleshooting
The error states the following:
For additional troubleshooting, check the Microsoft-SMA event logs on the computers in the Hybrid Runbook Worker Group that tried to run this job.
Let’s see where this log is and what’s in it.
Log on the Hybrid Worker
Go to Start and search for Eventvwr
Open the Applications and Services Log tab
Search for the tab Microsoft-SMA and open the log Operational

Okay let’s see what’s in it.
As you can see, different event logs are created per script.
A sandbox is started per script in which the script runs.
Then you see that the script is started and then you see an error.
The error itself is already clear enough.
Terminating sandbox on saving job stream error.

From now on we can assume that it is indeed the job stream.
But can we also check if the job is suspended in Azure Automation due to the size of the stream?
Well, yes and no. I can calculate the MB, but I cannot guarantee whether this is really correct because I am not 100% sure how Automation handles the different types of streams, for example,
- Is the warning stream, error stream & information stream separate from each other, or is this merged and sent to Automation?
- Is the stream just what’s shown on the console?
- or is the stream what’s in the output?
If you do know, I’d love to hear about it in the comments, but to make an estimate you could do the following.
Instead of out nulling the output, throw in an object:
$Object = Import-PSSession $Session -DisableNameChecking
$PSobject = $Object | Format-List *
$ByteCount = ([System.Text.Encoding]::UTF8.GetByteCount(($PSObject)))
$ByteCount / 1mb
The total MB is:
2.83146381378174
Which is more than 1 MB….
Endconclusion? either Out-Null them, or create a custom PSObject
for the response instead of streaming it to output.
We at least know why our job was suspended in Azure Automation.