How to execute PowerShell script as Azure Automation Runbook from InlineScript inside PSWorkflow runbook?
<p>In a PowerShell Workflow activity, I can call a native PowerShell script using InlineScript:</p>

<pre><code>workflow test
{
    InlineScript
    {
        .\script.ps1
    }
}
</code></pre>

<p>But in Azure Automation, the dot-path (at least in my tests) was returning <code>c:\windows\system32</code>, 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).</p>

<ol>
<li>Is it possible to execute a native PS runbook stored in AAuto like this?</li>
<li>If so, how do I specify the path to the file?</li>
<li>Is this a bug/oversight in Azure Automation's parsing/compilation process of Workflow runbooks &amp; InlineScript activities, preventing the dependent runbook from being copied to the worker?</li>
</ol>

<p>I did a little hunting, and found that when native PS runbooks are executed:</p>

<ol>
<li>They are first inspected for any other runbook references.</li>
<li>As part of the deployment to the worker for execution, a randomly-named folder is created under <code>C:\Temp\</code></li>
<li>Referenced runbooks are eventually copied to this folder. </li>
<li>If runbooks are NOT found to be referenced, they are NOT copied to the temp directory. </li>
<li>The root runbook does not appear to be copied to the folder.</li>
<li>The dynamically-named folder is NOT created (under c:\Temp) when executing a Workflow runbook.</li>
<li>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. </li>
</ol>

<p>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 &amp; paste the script into the first InlineScript within a workflow that requires it, which is obviously tedious &amp; annoying from a maintenance perspective.</p>

<p>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 &amp; having to maintain them separately, or AAuto not automatically pushing custom modules from the Automation Account to the worker (though this is planned), etc.</p>