Troubleshoot shared resource issues

This article discusses issues that might arise when you're using shared resources in Azure Automation.


Scenario: A module is stuck during import


A module is stuck in the Importing state when you're importing or updating your Azure Automation modules.


Because importing PowerShell modules is a complex, multistep process, a module might not import correctly, and can be stuck in a transient state. To learn more about the import process, see Importing a PowerShell module.


To resolve this issue, you must remove the module that is stuck by using the Remove-AzAutomationModule cmdlet. You can then retry importing the module.

Remove-AzAutomationModule -Name ModuleName -ResourceGroupName ExampleResourceGroup -AutomationAccountName ExampleAutomationAccount -Force

Scenario: AzureRM modules are stuck during import after an update attempt


A banner with the following message stays in your account after trying to update your AzureRM modules:

Azure modules are being updated


There is a known issue with updating the AzureRM modules in an Automation account. Specifically, the problem occurs if the modules are in a resource group with a numeric name starting with 0.


To update your AzureRM modules in your Automation account, the account must be in a resource group with an alphanumeric name. Resource groups with numeric names starting with 0 are unable to update AzureRM modules at this time.

Scenario: Module fails to import or cmdlets can't be executed after importing


A module fails to import, or it imports successfully, but no cmdlets are extracted.


Some common reasons that a module might not successfully import to Azure Automation are:

  • The structure doesn't match the structure that Automation needs.
  • The module depends on another module that hasn't been deployed to your Automation account.
  • The module is missing its dependencies in the folder.
  • The New-AzAutomationModule cmdlet is being used to upload the module, and you haven't provided the full storage path or haven't loaded the module by using a publicly accessible URL.


Use any of these solutions to fix the issue:

  • Make sure that the module follows the format: -> ModuleName or Version Number -> (ModuleName.psm1, ModuleName.psd1).
  • Open the .psd1 file and see if the module has any dependencies. If it does, upload these modules to the Automation account.
  • Make sure that any referenced .dll files are present in the module folder.

Scenario: Update-AzureModule.ps1 suspends when updating modules


When you're using the Update-AzureModule.ps1 runbook to update your Azure modules, the module update process is suspended.


For this runbook, the default setting to determine how many modules are updated simultaneously is 10. The update process is prone to errors when too many modules are being updated at the same time.


It's not common that all the AzureRM or Az modules are required in the same Automation account. You should only import the specific modules that you need.


Avoid importing the entire Az.Automation or AzureRM.Automation module, which imports all contained modules.

If the update process suspends, add the SimultaneousModuleImportJobCount parameter to the Update-AzureModules.ps1 script, and provide a lower value than the default of 10. If you implement this logic, try starting with a value of 3 or 5. SimultaneousModuleImportJobCount is a parameter of the Update-AutomationAzureModulesForAccount system runbook that is used to update Azure modules. If you make this adjustment, the update process runs longer, but has a better chance of completing. The following example shows the parameter and where to put it in the runbook:

        $Body = @"

Run As accounts

Scenario: You're unable to create or update a Run As account


When you try to create or update a Run As account, you receive an error similar to the following:

You do not have permissions to create…


You don't have the permissions that you need to create or update the Run As account, or the resource is locked at a resource group level.


To create or update a Run As account, you must have appropriate permissions to the various resources used by the Run As account.

If the problem is because of a lock, verify that the lock can be removed. Then go to the resource that is locked in Azure portal, right-click the lock, and select Delete.

Scenario: You receive the error "Unable to find an entry point named 'GetPerAdapterInfo' in DLL 'iplpapi.dll'" when executing a runbook


When you're executing a runbook, you receive the following exception:

Unable to find an entry point named 'GetPerAdapterInfo' in DLL 'iplpapi.dll'


This error is most likely caused by an incorrectly configured Run As account.


Make sure that your Run As account is properly configured. Then verify that you have the proper code in your runbook to authenticate with Azure. The following example shows a snippet of code to authenticate to Azure in a runbook by using a Run As account.

$connection = Get-AutomationConnection -Name AzureRunAsConnection
Connect-AzAccount -ServicePrincipal -Tenant $connection.TenantID `
-ApplicationID $connection.ApplicationID -CertificateThumbprint $connection.CertificateThumbprint

Next steps

If this article doesn't resolve your issue, try one of the following channels for additional support:

  • Get answers from Azure experts through Azure Forums.
  • Connect with @AzureSupport. This is the official Microsoft Azure account for connecting the Azure community to the right resources: answers, support, and experts.
  • File an Azure support incident. Go to the Azure support site, and select Get Support.