Search code examples
azureazure-automationazure-runbook

Modules could not be loaded error while executing Runbook manually after a month interval

I have general query regarding Automation Runbook.

I have Runbook which gets the VM Inventory details and I use to run it manually whenever i needed.

Question: If we don't use Automation Runbook for quite sometime(which is not Scheduled to run), wont it be able to work properly ? Like do we get any module errors if we run the Runbook after sometime (for e.g after 1 month).

Because when I ran it previously which worked perfectly and got the expected results but if i don't run it for like 2 or 3 weeks, when i try to run it again, it gives me "Modules could not be loaded" error. When i just try to re-import the modules once again and run couple of times then it works fine. Is it expected? has anyone encountered this error before?

Any suggestions will be helpful. Thanks.

Solution

  • Modules should not disappear just because you don't run a runbook for long time, at least not by design. However, importing, removing, or updating modules on the same Automation account may cause problems with module loading, even if these changes do not seem to be directly related to the runbook. If you are certain no changes have been performed on this Automation account, this behavior is definitely not expected.

    "Modules not installed/imported" is a bit vague, though. What is the exact error message you are getting and where do you see it?

    EDIT BASED ON THE COMMENTS:

    This error message ("The X command was found in the module Y, but the module could not be loaded") means that the module was found on the file system as expected, but it failed to auto-load into the current PS session. This can happen for many reasons. You will get a more detailed error message if you invoke Import-Module Az.Accounts from your runbook explicitly (if you are still able to reproduce this).

    It is important to understand that "importing a module" in the Azure Automation context means two different things:

    • Importing the module into the Automation account. After this is done, the module and the version appears on the list on the Portal. Now, the Automation service will make sure that the module files are deployed to the file system on the sandbox processes.
    • Importing the module into a PS session. This is what Import-Module does, and this is what PS tries to do automatically when you invoke a command defined in this module (auto-load). This is the step that failed in your situation.

    One common reason for this error is that PS sessions and sandbox processes can be reused in Azure Automation, and sometimes the session you get already has an incompatible module imported. For example, when using Az modules, you should be extra careful to not load AzureRM modules accidentally (see https://learn.microsoft.com/azure/automation/az-modules for more details). Even when you don't load AzureRM modules explicitly, they will be loaded if you try to invoke an AzureRM command from any runbook on this Automation account, or if you update or add AzureRM modules on this Automation account.

    This is just one example, but you may also have other conflicting modules and module versions imported into your Automation account. In any case, invoking Import-Module from your runbook should give you more details on your specific situation. I don't think just passing 2-3 weeks broke your runbook. I suspect something else was happening on this Automation account that made the reused PS session incompatible with this runbook. Importing or removing any module on this Automation account effectively makes the next job go to a brand new PS session in a brand new sandbox process, and I believe this is what resolved your issue.