With the release of the updated Azure PowerShell 1.0 Preview (October 2015), I was curious to see how much of a change would be required for me to continue to use Visual Studio 2015 to provision dev/test environments into my Azure account. When VS pushes an ARM template, it executes an auto generated PowerShell script named Deploy-AzureResourceGroup.ps1.
Here are the changes I made in order to get the script to execute successfully.
Change 1 – Module Check
The old code checked for the existence of the AzureResourceManager module. I updated the code to check for the new module named AzureRM
if (-NOT (Get-Module -ListAvailable | Where-Object {($_.Name -eq ‘AzureRM’) })) {
Throw “The version of the Azure PowerShell cmdlets installed on this machine are not compatible with this script.”
}
Change 2 – Import the module. Because the script still needs access to the Azure Service Management cmdlets, both the Azure and AzureRM modules need to be imported
Import-Module AzureRM -ErrorAction SilentlyContinue
Import-Module Azure -ErrorAction SilentlyContinue
Change 3 – Get the storage account key. The old code switches between AzureResourceManager and AzureServiceManagement depending on how the storage account was provisioned. The switching is no longer needed since now both the ASM and ARM cmdlets can be loaded and accessed at the same time. The code below will now retrieve the key in either case
if ($StorageAccountResourceGroupName) {
$StorageAccountKey = (Get-AzureRMStorageAccountKey -ResourceGroupName $StorageAccountResourceGroupName -Name $StorageAccountName).Key1
}
else {
$StorageAccountKey = (Get-AzureStorageKey -StorageAccountName $StorageAccountName).Primary
}
Change 4 – Create a connection for ARM. VS stores connection information for the old cmdlets and for ASM. For the new AzureRM cmdlets, a new connection needs to be established. In order to do this, I added in the new Login-AzureRMAccount cmdlet but only call it if there does not already exist a connection to ARM
try{
$AzureRMContext = Get-AzureRMContext
} catch {
Login-AzureRMAccount
}
Note – If you connect to more than one subscription or need to authenticate with more than one set of credentials, this cmdlet will have to be wrapped in additional logic
Change 5 – Deploy the resources. In the prior version of the code, the deployment is done directly through the New-AzureResourceGroup cmdlet. This cmdlet would update an existing resource group and force the replacement of resources, or deploy the RG from scratch if it did not exist. In the new version, we need to use the Get-AzureRMResourceGroup cmdlet to see if the RG is already there. If not, create it. Then, we need to use the New-AzureRMResourceGroupDeployment cmdlet to actually land the resources in the RG
$ResourceGroup = Get-AzureRMResourceGroup | where{$_.ResourceGroupName -eq $ResourceGroupName}
if($ResourceGroup -eq $null) {
Write-Host “Provisioning Resource Group: $ResourceGroupName in Location: $ResourceGroupLocation”
New-AzureRMResourceGroup -Name $ResourceGroupName -Location $ResourceGroupLocation
} else {
Write-Host “Resource Group: $ResourceGroupName Exists”
}New-AzureRMResourceGroupDeployment -Name $ResourceGroupName `
-ResourceGroupName $ResourceGroupName `
-TemplateFile $TemplateFile `
-TemplateParameterFile $TemplateParametersFile `
@OptionalParameters `
-Force -Verbose
That’s the gist of the changes. The only difference in the actual deployment through VS is that I now get prompted for the AzureRM credentials in order to connect if a connection does not already exist.
Happy cloud deploying!