Powershell – Get-AutomationPSCredential fails intermittently in Azure Automation

azurepowershell

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?

Best Answer

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:

Execute Get-AutomationPSCredential in a try/catch loop, sleeping for 30 seconds between retries.
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.

Related Solutions

Powershell error when adding filepath

One fix: the format and out need to follow the pipeline of the outer Foreach-Object:

$searchOU='ou=Servers,dc=mydomain,dc=NET'
Get-ADComputer -filter * -SearchBase $searchOU | 
  Foreach-Object {
    $server = $_.Name
    ([ADSI]"WinNT://$($_.Name)/Administrators").psbase.invoke('Members') | 
      ForEach-Object {
            $user = $_.GetType().InvokeMember('Name', 'GetProperty', $null, $_, $null)

            New-Object 'PSObject' -property @{'Server'=$server; 'Admin'=$user}
       }
 } | Format-Table -AutoSize Server, Name | Out-File C:\Scripts\servers.txt

Second: the error is coming from the ADSI Invoke call, probably unable to resolve the machine name.

Sql-server – Powershell execution policy within SQL Server

First, run the powershell command "Get-ExecutionPolicy -List" (as mentioned in the error message). This will give you a list of the different execution policy scopes and which setting is defined in which scope.

This list of scopes has an order of precedence (MachinePolicy, UserPolicy, Process, CurrentUser, LocalMachine). Each of these scopes can have a different setting;

Restricted
AllSigned
RemoteSigned
Unrestricted
Bypass
Undefined

Powershell will evaluate these scopes in the order listed and apply the first setting that is set to something other than 'Undefined'.

The error you're getting when running 'Set-ExecutionPolicy' indicates that you have a setting of 'Restricted' defined at a more specific scope than the default of LocalMachine. The Get-ExecutionPolicy -List cmdlet will tell you where.

If the Restricted setting is applied in either the LocalUser or Process scopes then you can change this. Use the Set-ExecutionPolicy cmdlet, but specify the scope using the -scope parameter. For example;

Set-ExecutionPolicy -Scope Process RemoteSigned

If the Restricted setting is defined at either the MachinePolicy or UserPolicy scopes then this indicates your domain administrators have configured a group policy that is overriding your local settings. This is where you would need to go and talk to them and see if you can have a less restrictive setting applied via GPO.

To the best of my knowledge you cannot easily override the GPO settings locally; however if I'm wrong on this then someone please do correct me! :)

Best Answer

Related Solutions

Powershell error when adding filepath

Sql-server – Powershell execution policy within SQL Server

Related Topic