0
votes

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).

  1. Is it possible to execute a native PS runbook stored in AAuto like this?
  2. If so, how do I specify the path to the file?
  3. 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:

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

1
here is the feedback idea for this j.mp/1mbTnt8 [feedback.azure.com]JoeBrockhaus

1 Answers

1
votes

Please see https://azure.microsoft.com/en-us/blog/announcing-powershell-script-support-azure-automation-2/:

Right now, you can only invoke inline PowerShell runbooks from PowerShell runbooks, and PowerShell Workflow or Graph runbooks from PowerShell Workflow or Graph runbooks. This may change in the future.

It hasn't changed yet :)