As of March 29th, Microsoft made the decision to publish new VM’s which archived a bunch of Az, Azure, and AzureRM modules.
The side effect of this was that when the deployment API scripts were run in Azure DevOps, it would throw an error when trying to load the Azure.Storage module.
'Azure.Storage' version 4.4.0 or greater is required.
At C:\Users\VssAdministrator\Documents\WindowsPowerShell\Modules\EpiCloud\0.13.15\EpiCloud.psm1:189 char:13
+ throw "'Azure.Storage' version 4.4.0 or greater is requir ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: ('Azure.Storage'...er is required.:String) [], RuntimeException
+ FullyQualifiedErrorId : 'Azure.Storage' version 4.4.0 or greater is required.
Script Updates
Until Optimizely (Episerver) puts in a fix to their EpiCloud scripts, I have put a fix into my scripts.
The fix will force install the Azure.Storage module into the scope of the release.
Write-Host "Installing Azure.Storage Powershell Module"
Install-Module -Name Azure.Storage -Scope CurrentUser -Repository PSGallery -Force -AllowClobber
This will produce a warning in some situations, which can be ignored. This is quite hard to remove, at the moment. I will keep at it and see if I can make an update later.
My scripts, EpiCloud-Scripts, have been updated with the fix and are ready for use.
Hi Eric! Thanks for posting this workaround so quickly! It turns out our error message is slightly misleading. We support both Azure.Storage and the newer Az.Storage. This error message is thrown if Azure.Storage is indeed installed on the VM but is too old. We’ll update the error message to better reflect this soon but just wanted to point out that the newer module Az.Storage is indeed supported by EpiCloud.
Hey Anders,
I actually first used the Az.Storage as my workaround, which worked perfectly, but it came with an even more ominous warning (not just on the upload method), so just for being user friendly, I changed it back to Azure.Storage.
I tried for a while removing AzureRM from the VM with no success (I believe there is a current bug). If AzureRM gets removed, I believe the warning will go away.
Ahh, that makes sense. I guess this is one of the downsides with using the prebuilt agents, sort of dependent on how Microsoft configures them. Let’s see what long term solution we can find for this problem! Thanks again for the quick post with a workaround, very appreciated!