Cannot run Azure Powershell 3.4 - Add-AzureAccount or Azure.Storage not loaded

Hi, I am getting the following errors:

Add-AzureAccount : The ‘Add-AzureAccount’ command was found in the module
15:36:44Error
’Azure’, but the module could not be loaded. For more information, run
15:36:44Error
’Import-Module Azure’.

Or if I have this Import-Module “C:\Program Files (x86)\Microsoft SDKs\Azure\PowerShell\ServiceManagement\Azure\Azure.psd1” inside the scrip I get this error:

Import-Module : The required module ‘Azure.Storage’ is not loaded. Load the
15:18:10Error
module or remove the module from ‘RequiredModules’ in the file ‘C:\Program
15:18:10Error
Files (x86)\Microsoft
15:18:10Error
SDKs\Azure\PowerShell\ServiceManagement\Azure\Azure.psd1’.

I am on version 3.3.22 and I am trying to run Azure Powershell 3.4 from it’s local storage at C:\Program Files (x86)\Microsoft SDKs\Azure\PowerShell\ServiceManagement\Azure.

I have set the Variable Octopus.Action.Azure.UseBundledAzurePowerShellModules = False and I have this in the Octopus.Server.Config C:\Program Files (x86)\Microsoft SDKs\Azure\PowerShell\ServiceManagement\Azure\Azure.psd1

I ran this $env:PSModulePath += “;C:\Program Files (x86)\Microsoft SDKs\Windows Azure\PowerShell” on the server.

If I run this script on the server, it works but if I run from Octopus Deploy it fails:

Write-Host ("[Start] Set up azure credentials Windows environment")
$credential = New-Object System.Management.Automation.PSCredential ($DeployUsername, $(ConvertTo-SecureString $DeployPassword -AsPlainText -Force))
Add-AzureRmAccount -Credential $credential
Add-AzureAccount -Credential $credential
Select-AzureSubscription -SubscriptionId $SubscriptionId -Default
Set-AzureRmContext -SubscriptionId $SubscriptionId

What am I missing?

Regards
Marqus Landin

Hi Marqus,

Thanks for getting in touch. Sorry to hear you’re having trouble getting your scripts to run. To make sure I understand your environment and requirements, I’ll just need to get some additional information.

Is the step in your deployment process a “Run a script” or a “Run an Azure PowerShell script” step? UseBundledAzurePowerShellModules only takes effect for the latter, but we do have customers who use “Run a script” and load the Azure modules manually so I just wanted to check. The setting you mentioned in the Octopus.Server.config was used in 3.2, so you don’t need it set (it shouldn’t do any harm if it is there but 3.3+ doesn’t use it)

If you are using the Azure PowerShell step, it does the authentication for you (the code is available on GitHub in case you haven’t already seen it) based on the Azure Account settings in Octopus Deploy. If your script is trying to authenticate again it’s possible that is causing the issue.

Also, where you mentioned $env:PSModulePath the path had “Windows Azure”, whereas the other paths just had Azure. Not sure that this would cause the issue you’re seeing, and it could be just a typo in your message, but thought I’d mention it.

Regards
Shannon

Hi I solved it by restarting the server, the only thing I did was that I
installed Azure Powershell 3.4 on the Octopus Server but I did not restart
the entire server.

But for my clarification, to understand how it works :wink:

We are running Run a script since we did not want to specify the account
(subscription) to use, we have 3 subscriptions so that would mean a
repeating script times 3. And also we want to be able to run the script
locally.

What I don’t understand is why it just broke when I upgraded Azure
Powershell on the Server, if the setting is not used in 3.3 and
UseBundledAzurePowerShellModules only works for Run an Azure Powershell
script. Then it should have no effect that I upgraded Azure Powershell or
is it when we then use Run a script, and it acknowledges Azure it will then
use the installed on server Azure powershell. Just wondering?

Regards
Marqus

Glad to hear it’s working.

As to exactly why it didn’t work before the reboot, I’m not sure. I can only imagine there was something cached in the environment that wasn’t being reset until the reboot. It’s possible that just restarting the Octopus Deploy service may have been enough to correct it, but it also wouldn’t surprise me if it was something at a lower level in the operating system and requires a reboot.

Regards
Shannon