Every so often, we find an Azure Automation Runbook fails with the following error:

Get-AutomationPSCredential : The term 'Get-AutomationPSCredential' is not recognized as the name of a cmdlet, function, 
script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is 
correct and try again.
At line:1 char:9
+ $cred = Get-AutomationPSCredential -Name SqlJobRunner
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (Get-AutomationPSCredential:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

Different runbooks of ours fail with this error, seemingly at random.

Get-AutomationPSCredential is an Azure-provided module. It's not our code, it's Microsoft's.

And sometimes, it appears to just "go away".

So what's happening here? Is the Azure Automation infrastructure reloading or updating modules at an inopportune time for our job? I was under the impression that once a runbook is scheduled, the dependent modules are "bound" to the runbook, so they'll be there when needed.

Why does this happen and what's the best defense against failure?


I received a call from Microsoft Azure support with the root cause.

Azure Automation in my region (East US) is running on PowerShell 5.0. They said there is a problem in 5.0 in that modules are loaded asynchronously. Cross-module dependencies are therefore not guaranteed to be available.

They told me the defect will be fixed in August when they release PowerShell 5.1 to the East US region.

They offered two mitigations:

  1. Execute Get-AutomationPSCredential in a try/catch loop, sleeping for 30 seconds between retries.
  2. Use a hybrid worker to farm the work out to a VM which has PowerShell 5.1 installed.

Another mitigation would be to import the required module where I need it. A complication of doing so is that the function in question, Get-AutomationPSCredential, comes from a different assembly in local development than when executing in the Automation context. In local development using the Azure Automation Authoring Toolkit, the command resides in assembly AzureAutomationAuthoringToolkit. In Azure, it's in Orchestrator.AssetManagement.Cmdlets.

I'm going to try simply this: Import-Module Orchestrator.AssetManagement.Cmdlets -ErrorAction SilentlyContinue

When executing in the ISE environment, the function will always be there, and this Import-Module will fail silently.

  • Also seeing this behavior as of May 22 in South Central US region, very random and rare. Thanks for digging in with support. – Noah Stahl May 22 '17 at 23:28

According to your description, we should check if the module has import. If not, we should import it.

We can use portal to check it:

Automation account-> modules->Orchestrator.AssetManagement.Cmdlets: enter image description here

If we does not import it, we should use portal to import this module:

enter image description here

enter image description here

  • The runbook works fine 99% of the time. Once in a while, it fails with the error message I provided. Nothing about the runbook has changed. It simply, randomly, fails. Orchestrator.AssetManagement.Cmdlets is, and always has been, present. – Larry Silverman Mar 27 '17 at 14:13
  • Does the error occur in the same automation account? – Jason Ye Mar 27 '17 at 14:59
  • Yes. I have only one automation account. – Larry Silverman Mar 27 '17 at 16:05
  • @LarrySilverman It sounds strange, can you provide your script? – Jason Ye Mar 28 '17 at 3:09
  • It happens in multiple Runbooks which call a function in a custom module. The first line of the function in the module is: $cred = Get-AutomationPSCredential -Name SqlJobRunner. It errors out there. – Larry Silverman Mar 28 '17 at 13:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.