Document Details

#### Cause

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.

#### Resolution

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.

### <a name="module-fails-to-import"></a>Scenario: Module fails to import or cmdlets can't be executed after importing

#### Issue

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

#### Cause

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](/powershell/module/Az.Automation/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.

#### Resolution

Use any of these solutions to fix the issue:

* Make sure that the module follows the format: ModuleName.zip -> 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.

### <a name="all-modules-suspended"></a>Scenario: Update-AzureModule.ps1 suspends when updating modules

#### Issue

When you're using the [Update-AzureModule.ps1](https://github.com/azureautomation/runbooks/blob/master/Utility/ARM/Update-AzureModule.ps1) runbook to update your Azure modules, the module update process is suspended.

#### Cause

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.

#### Resolution

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.

> [!NOTE]
> 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:

### <a name="update-azure-modules-importing"></a>Scenario: AzureRM modules are stuck during import after an update attempt

#### Issue

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

## Run As accounts

> [!NOTE]
> Azure Automation Run as accounts, including  Classic Run as accounts have retired on **30 September 2023** and replaced with [Managed Identities](../automation-security-overview.md#managed-identities)
You would no longer be able to create or renew Run as accounts through the Azure portal. For more information, see [migrating from an existing Run As accounts to managed identity](../migrate-run-as-accounts-managed-identity.md#sample-scripts).


### <a name="iphelper"></a>Scenario: You receive the error "Unable to find an entry point named 'GetPerAdapterInfo' in DLL 'iplpapi.dll'" when executing a runbook

#### Issue

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