Dynamically Deploy Certificate from Azure Key Store

I am unable to run the “Azure Key Vault - Retrieve Secrets” step from my docker image worker it fails telling me that it can’t find PowerShell.

Note that the same docker image/worker combination is used to run other PowerShell Key Vault commands so I think this is linked to how this step is being executed. My gut thinks this is because the image is a nanoserver image (Tag:windows-nanoserver-1809) i.e. PowerShell core. There is no option on this step to set the PowerShell version as a core version as I had to do with the Script Steps.


  • Docker Image works fine with native PowerShell scripts
  • “Azure Key Vault - Retrieve Secrets” step can’t access PowerShell on the image

I think there needs to be a similar way to configure the PowerShell context than the Script steps (Configure Features > PowerShell edition).

It is extremely frustrating to have different requirements and capabilities over the same problem area, not being able to re-use images for the same purpose points to a missing feature in this step config. Can you please point me to the correct use of the step or push to get this added (If my hunch is correct).

I expect my best solution now is to manually write the scripts and push the cert into an output variable but I have no idea how Octopus have done that, if this is required, can you please share the PowerShell commands to retrieve the certificate and push it into a sensitive output variable from the Azure Key store (How this step is doing it in the background) so that I can make sure it is compatible with downstream Octopus tasks.


Hi @mariusv

I wrote the original step template, and I must admit I didn’t consider running the step template on a windows server nano image. I incorrectly assumed that Windows PowerShell (Desktop) would be available on all Windows platforms.

With that being said, I understand why you would like to be able to set the PowerShell edition. Unfortunately adding the parameter which is indeed available in the base step (Run an Azure PowerShell script step) in the step template wouldn’t actually help.

The reason being is that the feature toggle can’t be bound to a variable, and therefore any changes to this value would be hard-coded to either Windows PowerShell or Core. This is a limitation in the product itself, which I’ll bring up with the engineers separately:

As the step could be used on both Linux and Windows, I’m hesitant to force it to always use PS Core, as this limits the use of the step template to force people to use PS Core. Whilst this does indeed make sense long-term, we try to keep step templates written by Octopus available to as many users and platforms as possible.

So coming back round to your issue, there are a few options:

Make a copy of the step template and change the Edition of PowerShell

  1. Take a copy of the step template. You can do this by clicking Save Copy:

  2. Then you could configure the features and select the PowerShell Edition

  3. Then set the edition to PowerShell Core:

  4. Lastly, update your deployment or runbook process to use the step template copy.

Octopus creates a copy of the step template and publishes a Core only version to the Library

This is the same as the first option, but we do that work, and hard-code the version. I’m reluctant to do this for the reasons mentioned earlier.

Use the variable: Octopus.Action.PowerShell.Edition

You can force Octopus to select the edition of PowerShell to use using a special variable. If you set its value to Core, then pwsh will be used in favour of Windows PowerShell. Just a note, if you set this globally in a project, it will set it across all steps. To only do it on the retrieve secrets step, I’d recommend scoping it to the correct step like so:

You can see more about this variable here: Power Shell Core Support by TomPeters · Pull Request #449 · OctopusDeploy/Calamari · GitHub

For the quickest route to testing, I’d recommend trying out the variable mentioned above.

I hope that helps, but let me know if you have any questions!

Best regards,

Thanks Mark, appreciate taking the time to give detailed feedback. I will be tackling this again next week and will provide feedback then.

Hey @mariusv

You’re very welcome. I’ve done some more research and have some other ideas if we need them but the variable option is still the easiest option.

If you run into any issues, just let me know!

Best regards

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.