We are pleased to announce Azure PowerShell 1.0, now available on PowerShell Gallery and WebPI. With this release of Azure PowerShell, we welcome the following changes:
- Enable better support for Azure Resource Manager cmdlet use side by side with Azure Service Management cmdlets in Azure Automation. While Resource Manager cmdlets don’t ship out of the box in Azure Automation yet, they will soon. Until then, they can be imported manually as described here. Please follow Azure Automation for updates on when the modules will ship out of the box.
- Separate Azure Service Management and Resource Manager functionality to provide clarity regarding features of Azure the cmdlets target
- Enforce semantic versioning and ensure cmdlets authored against a given major version of Azure PowerShell will not encounter breaking changes from updates to Azure PowerShell
- Availability of Azure PowerShell through WebPI and PowerShell Gallery to enable quicker delivery of new features and defect resolutions
- Improvements in the Azure PowerShell documentation and continued focus on documentation
- Certificate Authentication Support for Azure Resource Manager
- Virtual Machine disk encryption through Azure Key Vault
- Introduction of Azure Data Lake and Notification Hub cmdlets
- Improvements for Resource Manager, Web Apps and many other Azure services
Azure PowerShell 1.0 and Azure PowerShell 0.9.x
Azure PowerShell 1.0 and Azure PowerShell 0.9.x will both be available for installation on WebPI. This is intended to allow users of Azure PowerShell 0.9.x time to upgrade existing scripts to 1.0. We are committed to fixing defects and supporting Azure PowerShell 0.9.x, but we will not be adding new features. New feature development will target Azure PowerShell 1.0 and above.
Delivering Azure PowerShell via PowerShell Gallery and WebPI
There are two main options for installation, PowerShell Gallery and WebPI. WebPI will receive monthly updates. We are targeting the first Tuesday of every month. PowerShell Gallery will receive updates on a continuous basis. If you are comfortable with installing from PowerShell Gallery, that will be the first channel for the latest and greatest in Azure PowerShell.
Installing Azure PowerShell 1.0 via WebPI
Installing Azure PowerShell 1.0 and greater from WebPI is the same experience as it was for 0.9.x (just click this install link). If you have Azure PowerShell 0.9.x installed, you will be prompted to uninstall 0.9.x. If you installed Azure PowerShell modules from PowerShell Gallery, the installer requires the modules be removed prior to installation to ensure a consistent Azure PowerShell Environment.
If you installed Azure PowerShell via PowerShell Gallery and would instead like to use the WebPI installation, please run the following prior to installing from WebPI.
# Uninstall the AzureRM component modules Uninstall-AzureRM # Uninstall AzureRM module Uninstall-Module AzureRM # Uninstall the Azure module Uninstall-Module Azure # Or, you can nuke all Azure* modules # Uninstall-Module Azure* -Force
Note: There is a known issue with PowerShell $env:PSModulePath that occurs when installing via WebPI. If your computer requires a restart due to system updates or other installations, it may cause the $env:PSModulePath to not include the path where Azure PowerShell is installed. This can be corrected by restarting the machine or adding the Azure PowerShell path to the $env:PSModulePath.
Note: If you have installed the PowerShell Gallery Azure modules, you will be asked to uninstall them. This is to prevent confussion about which modules you have installed and where they are located. PowerShell Gallery modules will normally install to %ProgramFiles%WindowsPowerShellModules. In contrast, the WebPI installer will install the Azure modules to %ProgramFiles%Microsoft SDKsAzurePowerShell. PowerShellGet will uninstall modules and leave behind locked .dlls and the folders they reside within if a module dependency is loaded when it's being uninstalled. If you have uninstalled your PowerShell Gallery modules and still receive the error on install, remove the Azure* folders in your %ProgramFiles%WindowsPowerShellModules folder.
Installing Azure PowerShell 1.0 via PowerShell Gallery
Installing Azure PowerShell 1.0 and greater from PowerShell Gallery is the same experience as it was for the Azure PowerShell 1.0 Preview.
# Install the Azure Resource Manager modules from PowerShell Gallery Install-Module AzureRM Install-AzureRM # Install the Azure Service Management module from PowerShell Gallery Install-Module Azure # Import AzureRM modules for the given version manifest in the AzureRM module Import-AzureRM # Import Azure Service Management module Import-Module Azure
What is happening in the above script?
The above script looks fairly innocuous, but there are many things going on here. The functionality in this module is central to the semantic versioning feature listed earlier in this post. Install-Module AzureRM installs a bootstrapping module for the AzureRM modules. This module contains cmdlets to help update, uninstall and import the AzureRM modules in a safe and consistent way.
The AzureRM module contains a list of modules and the version range (min and max) required to ensure no breaking changes will be introduced for the major version of AzureRM. For more information on semantic versioning, see: https://semver.org. This means you can author your cmdlets using a specific version of AzureRM and know that all of the modules installed via the bootstrapper, will introduce no breaking changes.
The second command, Install-AzureRM installs all of the modules declared in the bootstrapping module.
The third command, Install-Module Azure installs the Azure module. This module is the Service Management module from Azure PowerShell 0.9.x. This should have no major changes and be interchangeable for the previous version of the Azure module.
The fourth command, Import-AzureRM imports all of the modules in the AzureRM module's list of modules and versions. This ensures that the Azure PowerShell modules that are loaded are within the version range required by the AzureRM module.
The fifth command, Import-Module Azure imports the Azure Service Management module. Note, the Azure module and the AzureRM modules are loaded into your PowerShell session and can both be used together.
Most of the work done in the AzureRM module was done so that we could introduce module dependencies with a given minimum and maximum version range. This will be replaced with the more robust PowerShellGet module dependency resolver in the future.
Getting started with Azure PowerShell
Getting started with Azure PowerShell is as simple as ever. All you need to do is login via Login-AzureRmAccount and proceed scripting with Azure PowerShell.
# To login to Azure Resource Manager Login-AzureRmAccount # You can also use a specific Tenant if you would like a faster login experience # Login-AzureRmAccount -TenantId xxxx # To view all subscriptions for your account Get-AzureRmSubscription # To select a default subscription for your current session Get-AzureRmSubscription –SubscriptionName “your sub” | Select-AzureRmSubscription # View your current Azure PowerShell session context # This session state is only applicable to the current session and will not affect other sessions Get-AzureRmContext # To select the default storage context for your current session Set-AzureRmCurrentStorageAccount –ResourceGroupName “your resource group” –StorageAccountName “your storage account name” # View your current Azure PowerShell session context # Note: the CurrentStoargeAccount is now set in your session context Get-AzureRmContext # To import the Azure.Storage data plane module (blob, queue, table) Import-Module Azure.Storage # To list all of the blobs in all of your containers in all of your accounts Get-AzureRmStorageAccount | Get-AzureStorageContainer | Get-AzureStorageBlob
Above you will likely notice the Get-AzureRmContext cmdlet. This is a change from Azure PowerShell 0.9.x way of scripting in Azure PowerShell. Rather than using the Profiles, Azure PowerShell 1.0 uses Context within the current session for local state persistence. The context will keep track of the current Azure environment (public cloud or other), account, tenant, subscription and storage account. If you would like to execute cmdlets against other defaults, use Set-AzureRmContext. For more information on this cmdlet, run help Set-AzureRmContext.
Certificate Authentication with Azure Resource Manager
Certificate authentication has been one of our most requested features in Azure PowerShell. We're happy to announce we have added the ability for Azure PowerShell users to configure a service principal to use a certificate to authenticate rather than using tenant id, client id and secret. This feature enables customers to better leverage Azure functionality such as Azure Automation where service principal authentication was previously unavailable. Below is a script to help you get started with Azure PowerShell Certificate authentication in Azure Resource Manager.
# Login to Azure PowerShell
Login-AzureRmAccount
# Create the self signed cert
$currentDate = Get-Date
$endDate = $currentDate.AddYears(1)
$notAfter = $endDate.AddYears(1)
$pwd = "P@ssW0rd1"
$thumb = (New-SelfSignedCertificate -CertStoreLocation cert:localmachinemy -DnsName com.foo.bar -KeyExportPolicy Exportable -Provider "Microsoft Enhanced RSA and AES Cryptographic Provider" -NotAfter $notAfter).Thumbprint
$pwd = ConvertTo-SecureString -String $pwd -Force -AsPlainText
Export-PfxCertificate -cert "cert:localmachinemy$thumb" -FilePath c:certificatesexamplecert.pfx -Password $pwd
# Load the certificate
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate("C:certificatesexamplecert.pfx", $pwd)
$keyValue = [System.Convert]::ToBase64String($cert.GetRawCertData())
$keyId = [guid]::NewGuid()
Import-Module AzureRM.Resources
$keyCredential = New-Object Microsoft.Azure.Commands.Resources.Models.ActiveDirectory.PSADKeyCredential
$keyCredential.StartDate = $currentDate
$keyCredential.EndDate= $endDate
$keyCredential.KeyId = $keyId
$keyCredential.Type = "AsymmetricX509Cert"
$keyCredential.Usage = "Verify"
$keyCredential.Value = $keyValue
# Create the Azure Active Directory Application
$azureAdApplication = New-AzureRmADApplication -DisplayName "" -HomePage "" -IdentifierUris "" -KeyCredentials $keyCredential
# Create the Service Principal and connect it to the Application
New-AzureRmADServicePrincipal -ApplicationId $azureAdApplication.ApplicationId
# Give the Service Principal Reader access to the current subscription
New-AzureRmRoleAssignment -RoleDefinitionName Reader -ServicePrincipalName $azureAdApplication.ApplicationId
# Now you can login to Azure PowerShell with your Service Principal and Certificate
Login-AzureRmAccount -TenantId (Get-AzureRmContext).Tenant.TenantId -ServicePrincipal -Certificate Thumbprint $thumb -ApplicationId $azureAdApplication.ApplicationId
Web Apps Cmdlet Improvements
Azure Web Apps module has also been updated in the 1.0 release. Based on feedback from the community we have streamlined the usage of the Web Apps cmdlets by enabling better piping and listing of Web Apps across resource groups. The script below illustrates this better than words.
# Login if you haven't already Login-AzureRmAccount # Create a new resource group New-AzureRmResourceGroup -Location westus -Name webapptestrg # Create a new WebApp New-AzureRmWebApp -ResourceGroupName webapptestrg -Location westus -Name djtestwebapp # List all the WebApps for all of your resource groups # Note: better piping support Get-AzureRmResourceGroup | Get-AzureRmWebApp # List all WebApps for all of your resource groups # Note: this is the same thing as the previous command, but less key strokes Get-AzureRmWebApp
Azure Resource Manager improvements
As part of the Azure PowerShell 1.0 release, we made a few improvements to the management cmdlets. These improvements are in addition to the cmdlet name changes that are part of 1.0. The changes include the following. New-AzureRMResourceGroup provides the functionality of creating new resource groups, and New-AzureRmResourceGroupDeployment provides the functionality of deploying the template. You can use piping to use the two together. This makes the cmdlets easier to understand and use. Also, audit logs had numerous cmdlets to get logs at various scopes; such as, Get-AzureResourceProviderLog, Get-AzureResourceGroupLog, Get-AzureSubscriptionIdLog, and Get-AzureResourceLog.
To get logs, you often had to run a combination of the log cmdlets. This experience was not optimal. We have consolidated this functionality into a single cmdlet which can be called at different scopes through the use of parameters. Now, you can call Get-AzureRmLog with the appropriate parameter to specify the scope. For more information, check out Changes to Azure Resource Manager management PowerShell cmdlets.
Ready for Azure PowerShell 1.0?
Excited by these updates and want to get started? Install Azure PowerShell 1.0 from WebPI.