No Azure environment could be matched given the name AzureCloud - Second Node

(JoeBurnside) #1

We recently upgraded to v2019.2.1 to include Spaces on out octopus server. With advice from our TAM we turned on our “backup” server in order to get a second node to run more tasks at once and apply HA architecture.
We seem to be having a problem that has been flagged up several times before, however we are only experiencing this on one node.

The PS, CLI and Octopus versions are the same on both machines. Any help would be appreciated.

(Ben Pearce) #3

Hi Joe,

Thanks for getting in touch, sorry to see you have experienced this issue.

There are a couple of reasons that this error can occur.
Firstly, we are currently bundling Azure PowerShell modules version 6.13.1, which will require PowerShell version 5.1+ to be installed on the host server.
The second possibility is that you have the OctopusUseBundledAzureModules variable set to true in the project which will require the host server to have the Azure PowerShell modules installed. Installing your own copy of the Azure PowerShell modules might be a possible workaround.

Could you please turn on variable logging for your project where this is failing, re-deploy and then export the raw task log , then attach the log to this ticket for us to investigate?


(JoeBurnside) #4

Hi Ben,
The powershell version on both servers is 5.1.14409.1018.
We recently upgraded from Octopus 3.16.6 and have quite a bit of old AzureRm powershell code. For this reason, Azure Powershell version 5.0.1 is installed on both machines, and a global variable shared between all projects on the server of Octopus.Action.Azure.UseBundledAzurePowerShellModules set to False.

Attached a log with variables turned on. The step used actually does nothing (get-module –listavailable) but is used in an Azure Powershell step that errors out while connecting.

It just seems odd that everything works on one machine but not the other. ServerTasks-155430.log.txt (75.3 KB)

(Ben Pearce) #5

Hi Joe,

If you run that same script from the vanilla PowerShell script step rather than the Azure one, it will get a better view on what modules are available for the Octopus step execution.
I would also consider upgrading the version of the Azure PowerShell as there are a number of bug fixes and compatibility improvements since then. If you flip the UseBundledAzurePowerShellModules value back to true, this will unpack the bundled Azure PS modules (currently at 6.13.1) without impacting the installed version on the server.