Runbook can't call another runbook in the same automation account?

AJ Randazzo hi,

the error happens because the automation service has some legacy azurerm components preloaded in the background. when your runbook uses a cmdlet from the newer az module, it tries to load both, and they fight over the same namespaces, causing that 'does not have an implementation' crash.

here is what you can try to fix it.

first, check the 'modules' gallery in your automation account. sometimes an old 'azurerm' module is listed there, even if you did not put it there. if you see any module starting with 'azurerm', delete it. only the 'az' modules should be present.

next, in your parent runbook, try forcing the use of the az context at the very beginning. add these lines before you call start-azautomationrunbook.

disable-azcontextautosave -scope process connect-azaccount -identity

this tells the runbook to use the managed identity and not rely on any cached credentials that might be tied to the old modules.

if that does not work, the most reliable solution is to use a webhook. you are already using an http post as a workaround, and that is actually a very solid pattern. it completely avoids the module conflict by starting the child runbook in a fresh, isolated sandbox. you can create a webhook for the child runbook and then have the parent runbook invoke it with invoke-restmethod. it is a bit more setup, but it is guaranteed to work.

this kind of module conflict is not unique to azure automation. it can happen in any powershell environment where multiple versions of the same sdk are present. the webhook method is a clean way to enforce separation.

try removing any old azurerm modules and forcing the az context. if the conflict persists, embrace the webhook method. it is a more robust long term solution anyway.

good luck, my friend. i hope this clears up the module conflict for you.

rgds,

Alex