In a PowerShell Workflow activity, I can call a native PowerShell script using InlineScript:
workflow test
{
InlineScript
{
.\script.ps1
}
}
But in Azure Automation, the dot-path (at least in my tests) was returning c:\windows\system32
, and the script-as-runbook in Azure Automation did not exist there (or rather, it failed to execute because it could not find the script).
- Is it possible to execute a native PS runbook stored in AAuto like this?
- If so, how do I specify the path to the file?
- Is this a bug/oversight in Azure Automation's parsing/compilation process of Workflow runbooks & InlineScript activities, preventing the dependent runbook from being copied to the worker?
I did a little hunting, and found that when native PS runbooks are executed:
- They are first inspected for any other runbook references.
- As part of the deployment to the worker for execution, a randomly-named folder is created under
C:\Temp\
- Referenced runbooks are eventually copied to this folder.
- If runbooks are NOT found to be referenced, they are NOT copied to the temp directory.
- The root runbook does not appear to be copied to the folder.
- The dynamically-named folder is NOT created (under c:\Temp) when executing a Workflow runbook.
- As part of the standard Workflow compilation, InlineScript activities have their contents copied to the autogenerated xaml. I'm uncertain about a linked file, though based on behavior that looks to be a runtime concern. My guess is that compilation happens each time a workflow is executed (hence the delayed start), and takes place on the worker, utilizing the standard PS workflow compilation just like local would.
I cannot (easily) convert this script to a workflow, and it is used from within other workflow activities. Right now the only way I can make this 'work' is to copy & paste the script into the first InlineScript within a workflow that requires it, which is obviously tedious & annoying from a maintenance perspective.
Presumably, as a workaround, I could use a Hybrid Worker, but that comes with a host of other issues, like ensuring the child runbooks are published there & having to maintain them separately, or AAuto not automatically pushing custom modules from the Automation Account to the worker (though this is planned), etc.