Azure CLI and Azure PowerShell Build 2025 Announcement
The key investment areas for Azure CLI and Azure PowerShell in 2025 are quality and security. We’ve also made meaningful efforts to improve the overall user experience. In parallel, we've enhanced the quality and performance of Azure CLI and Azure PowerShell responses in Copilot, ensuring a more reliable user experience. We encourage you to try out the improved Azure CLI and Azure PowerShell in the Copilot experience and see how it can help streamline your Azure workflows. At Microsoft Build 2025, we're excited to announce several new capabilities aligned with these priorities: Improvements in quality and security. Enhancements to user experience. Ongoing improvements to Copilot's response quality and performance. Improvements in quality and security Azure CLI and Azure PowerShell Long Term Support (LTS) releases support In November 2024, Azure PowerShell became the first to introduce both Standard Term Support (STS) and Long-Term Support (LTS) versions, providing users with more flexibility in managing their tools. At Microsoft Build 2025, we are excited to announce that Azure CLI now also supports both STS and LTS release models. This allows users to choose the version that best fits their project needs, whether they prefer the stability of LTS releases or want to stay up to date with the latest features in STS releases. Users can continue using an LTS version until the next LTS becomes available or choose to upgrade more frequently with STS versions. To learn more about the definitions and support timelines for Azure CLI and Azure PowerShell STS and LTS versions, please refer to the following documentation: Azure CLI lifecycle and support | Microsoft Learn Azure PowerShell support lifecycle | Microsoft Learn Users can choose between the Long-Term Support (LTS) and Short-Term Support (STS) versions of Azure CLI based on their specific needs. It is important to understand the trade-offs: LTS versions provide a stable and predictable environment with a support cycle of up to 12 months, making them ideal for scenarios where stability and minimal maintenance are priorities. STS versions, on the other hand, offer access to the latest features and more frequent bug fixes. However, this comes with the potential need for more frequent script updates as changes are introduced with each release. It is also worth noting that platforms such as Azure DevOps and GitHub Actions typically default to using newer CLI versions. That said, users still have the option to pin to a specific version if greater consistency is required in their CI/CD pipelines. When using Azure CLI to deploy services like Azure Functions within CI/CD workflows, the actual CLI version in use will depend on the version selected by the pipeline environment (e.g., GitHub Actions or Azure DevOps), and it is recommended to verify or explicitly set the version to align with your deployment requirements. SecureString update for Azure PowerShell Our team is gradually transitioning to using SecureString for tokens, account keys, and secrets, replacing the traditional string types. In November 2024, we offered an opt-in method for the Get-AzAccessToken cmdlet. At the 2025 Build event, we’ve made this option mandatory, which is a breaking change: Get-AzAccessToken Get-AzAccessToken Token : System.Security.SecureString ExpiresOn : 5/13/2025 1:09:15 AM +00:00 TenantId : 00000000-0000-0000-0000-000000000000 UserId : user@mail.com Type : Bearer In 2026, we plan to implement this secure method in more commands, converting all keys, tokens, and similar data from string types to SecureString. Please continue to pay attention to our upcoming breaking changes documentation. Install Azure PowerShell from Microsoft Artifact Registry (MAR) Installing Azure PowerShell from Microsoft Artifact Registry (MAR) brings several key advantages for enterprise users, particularly in terms of security, performance, and simplified artifact management. Stronger Security and Supply Chain Integrity Microsoft Artifact Registry (MAR) enhances security by ensuring only Microsoft can publish official packages, eliminating risks like name squatting. It also improves software supply chain integrity by offering greater transparency and control over artifact provenance. Faster and More Reliable Delivery By caching Az modules in your own ACR instances with MAR as an upstream source, customers benefit from faster downloads and higher reliability, especially within the Azure network. You can try installing Azure PowerShell from MAR using the following PowerShell command: $acrUrl = 'https://mcr.microsoft.com' Register-PSResourceRepository -Name MAR -Uri $acrUrl -ApiVersion ContainerRegistry Install-PSResource -Name Az -Repository MAR For detailed installation instructions and prerequisites, refer to the official documentation: Optimize the installation of Azure PowerShell | Microsoft Learn Enhancements to user experience Azure PowerShell Enhancements at Microsoft Build 2025 As part of the Microsoft Build 2025 announcements, Azure PowerShell has introduced several significant improvements to enhance usability, automation flexibility, and overall user experience. Real-Time Progress Bar for Long-Running Operations Cmdlets that perform long-running operations now display a real-time progress bar, offering users clear visual feedback during execution. Smarter Output Formatting Based on Result Count Output formatting is now dynamically adjusted based on the number of results returned: A detailed list view is shown when a single result is returned, helping users quickly understand the full details. A table view is presented when multiple results are returned, providing a concise summary that's easier to scan. JSON-Based Resource Creation for Improved Automation Azure PowerShell now supports creating resources using raw JSON input, making it easier to integrate with infrastructure-as-code (IaC) pipelines. When this feature is enabled (by default in Azure environments), applicable cmdlets accept: JSON strings directly via *ViaJsonString External JSON files via *ViaJsonFilePath This capability streamlines scripting and automation, especially for users managing complex configurations. We're always looking for feedback, so try the new features and let us know what you think. Improved for custom and disconnected clouds: Azure CLI now reads extended ARM metadata In disconnected environments like national clouds, air-gapped setups, or Azure Stack, customers often define their own cloud configurations, including custom dataplane endpoints. However, older versions of Azure CLI and its extensions relied heavily on hardcoded endpoint values based only on the cloud name, limiting functionality in these isolated environments. To address this, Azure CLI now supports reading richer cloud metadata from Azure Resource Manager (ARM) using API version 2022-09-01. This metadata includes extended data plane endpoints, such as those for Arc-enabled services and private registries previously unavailable in older API versions. When running az cloud register with the --endpoint-resource-manager flag, Azure CLI automatically parses and loads these custom endpoints into its runtime context. All extensions, like connectedk8s, k8s-configuration, and others, can now dynamically use accurate, environment-specific endpoints without needing hardcoded logic. Key Benefits: Improved Support for Custom Clouds: Enables more reliable automation and compatibility with Azure Local. Increased Security and Maintainability: Removes the need for manually hardcoding endpoints. Unified Extension Behavior: Ensures consistent behavior across CLI and its extensions using centrally managed metadata. Try it out: Register cloud az cloud register -n myCloud --endpoint-resource-manager https://management.azure.com/ Check cloud az cloud show -n myCloud For the original implementation, please refer to https://github.com/Azure/azure-cli/pull/30682. Azure PowerShell WAM authentication update Since Azure PowerShell 12.0.0, Azure PowerShell supports Web Authentication Manager (WAM) as the default authentication mechanism. Using Web Account Manager (WAM) for authentication in Azure enhances security through its built-in identity broker and default system browser integration. It also delivers a faster and more seamless sign-in experience. All major blockers have been resolved, and we are actively working on the pending issues. For detailed announcements on specific issues, please refer to the WAM issues and Workarounds issue. We encourage users to enable WAM functionality using the command: Update-AzConfig -EnableLoginByWam $true. under Windows operating systems to ensure security. If you encounter issues, please report them in Issues · Azure/azure-powershell. Improve Copilot's response quality and performance Azure CLI/PS enhancement with Copilot in Azure In the first half of 2025, we improved the knowledge of Azure CLI and Azure PowerShell commands for Azure Copilot end-to-end scenarios based on best practices to answer questions related to commands and scripts. In the past six months, we have optimized the following scenarios: Introduced Azure concept documents to RAG to provide more accurate and comprehensive answers. Improved the accuracy and relevance of knowledge retrieval query and chunking strategies Support more accurate rejection of the out-of-scope questions. AI Shell brings AI to the command line, enabling natural conversations with language models and customizable workflows. AI Shell is in public preview and allows you to access Copilot in Azure. All the optimizations apply to AI Shell. For more information about AI Shell releases, see: AI Shell To learn more about Microsoft Copilot for Azure and how it can help you, visit: Microsoft Copilot for Azure Breaking Changes You can find the latest breaking change guidance documents at the links below. To learn more about the breaking changes, ensure your environment is ready to install the newest version of Azure CLI and Azure PowerShell, see the release notes and migration guides. Azure CLI: Release notes & updates – Azure CLI | Microsoft Learn Azure PowerShell: Migration guide for Az 14.0.0 | Microsoft Learn Milestone timelines: Azure CLI Milestones Azure PowerShell Milestones Thank you for using the Azure command-line tools. We look forward to continuing to improve your experience. We hope you enjoy Microsoft Build and all the great work released this week. We'd love to hear your feedback, so feel free to reach out anytime. GitHub: o https://github.com/Azure/azure-cli o https://github.com/Azure/azure-powershell Let's stay in touch on X (Twitter) : @azureposh @AzureCliAn Update on Bicep Azure Verified Modules for Platform Landing Zone (ALZ)
But first some history and context As you may of heard in one of our Azure Landing Zone (ALZ) community calls over the past year, across ALZ we have been working hard to refactor both our Terraform and Bicep implementation options to be built upon Azure Verified Modules (AVM). Earlier this year we announced that the work for Terraform, which we started on first, was complete; and you can read more about that in the announcement blog post we posted here. But whilst this work was going on the ALZ Bicep team where already busy planning how they would go about doing the same and rebuilding ALZ Bicep from AVM modules. You can see the original plans and where we also asked for feedback in the GitHub issue (#791) . Enough history, what's the latest? Now to answer the question everyone has and rightly so 😁 Well, it's good news! We have been busy working away on getting a number of the AVM Bicep Resource Modules updated with missing bits and pieces that we need from an ALZ perspective. All fairly minor in most cases but some required some bigger updates than others, and some modules didn't exist at all so we have had to propose, create, and publish those of which we are pretty much done with 👍 We are still working towards an end of Q4 (June/July) target for a preview release of all the modules, accelerator and guidance on how to use the new version of ALZ Bicep, which will be called "Bicep Azure Verified Modules for Platform Landing Zone (ALZ)"; this is to align with Terraform and also to provide clear distinction between ALZ Bicep and the new AVM based version. Please note that the timeline shared above is an ETA and may move Announcing the preview release of `avm/ptn/alz/empty` AVM Pattern Module Before we get to a more complete release of all the required resources and modules to build the entire ALZ architecture with the new Bicep Azure Verified Modules for Platform Landing Zone (ALZ), we wanted to share an early look at the module that will be at the heart of all of your ALZ deployments. That module is called `avm/ptn/alz/empty` and is available in the Public Bicep Registry for you to try out today (currently version `0.1.0`)! Tip: Checkout the "max" test in the tests directory for advanced usage examples! module testMg 'br/public:avm/ptn/alz/empty:0.1.0' = { params: { managementGroupName: 'test-mg' // Other parameters here... } } This module is 1 of 11 modules that will all be based off the same code. The module optionally creates all of the below: The Management Group itself Can also target an existing Management Group Management Group Subscription Associations RBAC Custom Role Definitions RBAC Role Assignments Policy Assignments Custom Policy Definitions Custom Policy Set Definitions (Initiatives) There will also be 1 x Bicep Azure Verified Modules for Platform Landing Zone (ALZ) pattern module for each of the ALZ Architectures Management Groups, plus this empty one for custom and advanced scenarios. A reminder of those Management Groups and the associated modules that will be created for each of them: `avm/ptn/alz/int-root` `avm/ptn/alz/platform` `avm/ptn/alz/platform-management` `avm/ptn/alz/platform-identity` `avm/ptn/alz/platform-connectivity` `avm/ptn/alz/landing-zones` `avm/ptn/alz/landing-zones-corp` `avm/ptn/alz/landing-zones-online` `avm/ptn/alz/decommissioned` `avm/ptn/alz/sandbox` These Management Group aligned pattern modules will create the same resources as above, but will have the latest release of the ALZ Library baked in to each of the modules. Meaning that for the `avm/ptn/alz/int-root` pattern module, you won't have to declare all of the ALZ RBAC Custom Role Definitions, Custom Policy Definitions, Policy Assignments etc. via the input parameters as they'll be hardcoded in the module based off the latest release from the ALZ Library at the point the version of the module was released. This means that to build the ALZ Management Group hierarchy and make all of the default ALZ policy assignments, as documented here, you'd need a bicep file that would look something like this as a starting point: Important: None of these modules exist below today! module intRootMg 'br/public:avm/ptn/alz/int-root:0.1.0' = { params: { managementGroupName: 'int-root-mg' } } module platformMg 'br/public:avm/ptn/alz/platform:0.1.0' = { params: { managementGroupName: 'platform-mg' managementGroupParentId: intRootMg.outputs.managementGroupId } } module platformConnectivityMg 'br/public:avm/ptn/alz/platform-connectivity:0.1.0' = { params: { managementGroupName: 'platform-mg' managementGroupParentId: platformMg.outputs.managementGroupId } } This will make getting the ALZ Architecture out of the box really fast, and also really easy to upgrade and get the latest updates, by just bumping the version number as you desire when you are ready. Coupled with the `avm/ptn/alz/empty` module to add your own additional Policy Definitions and assignments, etc. at the same Management Groups scopes also helps you decouple the constant updates to the ALZ architecture and policies etc. from your own additional requirements. Helping you keep your code cleaner and our modules simple to maintain as we won't have to cater for handling additional custom definitions and assignments alongside the defaults from ALZ that are baked into the modules. Note: We are looking at suggesting that all of these are deployed via Deployment Stacks to help with lifecycle management of resources. e.g. help clean-up resources as well as deploy new ones; think policy assignments and definitions etc. We need to complete a lot more testing on this, but would love your feedback on experiences if you have any using Deployment Stacks to manage these kind of resources today. Open an issue/discussion on the ALZ Bicep GitHub repo 👍 Our asks to you 🫵 Please go try out and test the new `avm/ptn/alz/empty` module and test it out for all the scenarios you can think of relating to Management Groups, RBAC, Policies etc. we want to make sure it's "match fit/ready" before we then build the Management Group aligned modules and bake in the ALZ defaults to them. So please go and put the module through its paces and test it out. Tip: Checkout the "max" test in the tests directory for advanced usage examples! If you find any issues, bugs, feature requests or just have a question on how to use it, please just raise them as GitHub issues here (make sure to select the `avm/ptn/alz/empty` module from the drop down 👍) Thanks in advance for all your efforts and assistance and we look forward to hearing and getting your feedback on the module 👏Announcing General Availability of Terraform Azure Verified Modules for Platform Landing Zone (ALZ)
Azure Verified Modules ALZ ❤️ AVM. We are moving to a more modular approach to deploying your platform landing zones. In line with consistent feedback from you, we have now released a set of modules that together will deploy your platform landing zone architecture (ALZ). Azure Verified Modules for Platform Landing Zones (ALZ) is collection of Azure Verified Modules that are composed together to create your Platform Landing Zone. This replaces the existing CAF Enterprise Scale module that you may already be familiar with. The core Azure Verified Modules that are composed together are: Management Groups and Policy Pattern Module: avm-ptn-alz Management Resources Pattern Module: avm-ptn-management-alz Hub Virtual Networking Pattern Module: avm-ptn-hubnetworking Virtual Network Gateway Pattern Module: avm-ptn-vnetgateway Virtual WAN Networking Pattern Module: avm-ptn-virtualwan Private DNS Zone for Private Link Pattern Module: avm-ptn-network-private-link-private-dns-zones This means that you can now choose your own adventure by selecting only the modules that you need. It also means we can add new features faster and allows us the opportunity to do more rigorous testing of each module. To improve deployment reliability, we now use our own Terraform provider. The provider generates data for use by the module and does not directly deploy any resources. The move to a provider allows us to add many more features and checks to improve your deployment reliability. ALZ IaC Accelerator updates for Terraform The Azure Landing Zones IaC Accelerator is our recommended approach for deploying the Terraform Azure Verified Modules for Platform Landing Zone (ALZ). The Azure Verified Modules for Platform Landing Zone is now our default selection for the Terraform ALZ IaC Accelerator. This module will be the focus of our development and improvement efforts moving forward. The module implements best practices by default, including multi-region and availability zones for resiliency. The ALZ IaC Accelerator bootstrap continues to implement best practices, such as version control and Workload identity federation security. Along with supporting the Azure Verified Modules for Platform Landing Zone (ALZ) approach, we have also made many enhancements to the ALZ IaC Accelerator process. A summary of the improvements include: We now support HCL (HashiCorp Configuration language) tfvars file as the platform landing zone configuration file format We have introduced a Phase 0 to help you plan for your ALZ IaC Accelerator deployment We have introduced the concepts of Scenarios and Options to simplify the decisions you need to make Platform landing zone configuration file Before the introduction of the Azure Verified Modules for Platform Landing Zone (ALZ) starter module the platform landing zone configuration file was supplied in YAML format. Due to the lack of support for YAML in Terraform, we had to then convert this to JSON. Once converted to JSON the configuration file lost all it's ordering, formatting and comments. This made day 2 updates to the configuration very cumbersome. With the support for the tfvars file (in HashiCorp Configuration Language format), we are now able to pass the configuration file in its original format to the version control system repository. This makes for a much easier day 2 update process as the file retains it's ordering, comments and formatting as defined by you. Phase 0 Phase 0 is a new planning phase we have added to the documentation. This phase takes you through 3 sets of decisions you need to make about the ALZ IaC Accelerator deployment: Bootstrap decisions Platform Landing Zone Scenarios Platform Landing Zone Options In order to assist with this, we also provide a downloadable Excel checklist , which lists all the decisions so you can consider them up front prior to completing any configuration file updates. Phase 0 guides you through this process and provides explanations of the decisions. The Bootstrap decisions relate to the resources deployed to Azure and the configuration of your Version Control System required for the Continuous Delivery pipeline. These decisions are not new to the ALZ IaC Accelerator, but we now provide more structured guidance. Platform Landing Zone Scenarios The Scenarios are a new concept introduced for the Azure Verified Modules for Platform Landing Zone (ALZ) starter module. We aim to cover the most common Platform landing zone use cases we hear requested from partners and customers with the ALZ IaC Accelerator. These include: Multi-Region Hub and Spoke Virtual Network with Azure Firewall Multi-Region Virtual WAN with Azure Firewall Multi-Region Hub and Spoke Virtual Network with Network Virtual Appliance (NVA) Multi-Region Virtual WAN with Network Virtual Appliance (NVA) Management Groups, Policy and Management Resources Only Single-Region Hub and Spoke Virtual Network with Azure Firewall Single-Region Virtual WAN with Azure Firewall For each scenario we provide an example Platform landing zone configuration file that is ready to deploy immediately. We know that customers will want to modify some of the settings and that is where Options come in. NOTE: At the time this blog post was published, we support the 7 Scenarios listed above. We may update or add to these Scenarios based on feedback we hear from you, so keep an eye on our documentation. Platform Landing Zone Options The Options build on the Scenarios. For each Scenario, you can choose to customise it with one or more Options. Each Options includes detailed instructions of how to update the Platform landing zone configuration file or introduce library files to implement to the option. The Options are: Customise Resource Names Customize Management Group Names and IDs Turn off DDOS protection plan Turn off Bastion host Turn off Private DNS zones and Private DNS resolver Turn off Virtual Network Gateways Additional Regions IP Address Ranges Change a policy assignment enforcement mode Remove a policy assignment Turn off Azure Monitoring Agent Deploy Azure Monitoring Baseline Alerts (AMBA) Turn off Defender Plans Implement Zero Trust Networking NOTE: At the time this blog post was published, we support the 14 Options listed above. We may update or add to these Options based on feedback we hear from you, so keep an eye on our documentation. Azure Landing Zones Library Another new offering is the Azure Landing Zones Library. This is an evolution of the library concept in the caf-enterprise-scale module. Principally, the Library allows us to decouple the update cycle of the ALZ architecture, from the module and provider. We are separating the data from the deployment logic. This allows you to update the module to take advantage of a bug fix, without having to change the policies that are deployed. Something that wasn't easily possible before. Conversely, you are able to update to the latest policy refresh of Azure Landing Zones without updating the module itself. The Library has its own documentation site, which introduces the concepts. We plan to make the library the single source of truth for all Azure Landing Zones implementation options (e.g. Portal, Terraform and Bicep) in the future. Azure Landing Zones Documentation Site Furthermore, we have a new place to go for all technical documentation for Azure Verified Modules for Platform Landing Zones (ALZ). With the move to multiple modules, and the new accelerator all having multiple GitHub repositories, we felt the need to centralize the documentation to make it the one place to go to get technical details. We currently have documentation for the Accelerator and Terraform, with Bicep coming soon. The new vanity URL is: https://aka.ms/alz/tech-docs. Please let us know what you think! What about ALZ-Bicep? Finally, some of you may be wondering what the future for our Bicep implementation option (ALZ Bicep) for Azure Verified Modules for Platform Landing Zones (ALZ) may be with this evolution on the Terraform side. And we have good news to share! Work is underway to also build the next version of ALZ in Bicep, which will be known as “Bicep Azure Verified Modules for Platform Landing Zone (ALZ)”. This will also use the new Azure Landing Zones Library and be built from Azure Verified Modules (where appropriate). We are currently looking to complete this work before August 2025, if not a lot sooner than this; as we are making good progress as we speak! But for now, for Bicep you do not do anything and continue to use ALZ Bicep via the ALZ IaC Accelerator and we will provide more updates on the next version of Bicep ALZ in the coming months! Staying up-to-date We highly recommend joining, or watching back, our quarterly Azure Landing Zones Community Calls, to get all the latest and greatest from the ALZ team. Our next one is on the 29th January 2025 and you can find the link to sign up to attend or watch back previous ones at: aka.ms/ALZ/Community We look forward to seeing you all there soon!Azure CLI and Azure PowerShell Ignite 2024 Announcement
The priority for Azure CLI and Azure PowerShell remains to provide our customers with the most complete, secure, and easy-to-use tools to manage Azure resources. At Microsoft Ignite 2024, we are announcing the following new capabilities delivering on our priorities: Extending our coverage and commands API version upgrade. Security improvements. Investments in Copilot in Azure Extending our coverage In the past six months, we have added or refreshed coverage for new or existing Azure services within 30 days of their general availability. You will see new and updated command lines for ArcGateway, AzTerraform, ConnectedMachine, Fabric, Astro, Synapse, AppComplianceAutomation, Storage, App, and other modules. Note: To use the associated commands, you need to install the Azure CLI extension or the Azure PowerShell module. For details about all the commands that have been updated, as well as a complete list of the new features in this release for the Azure client tools, see the release notes for each tool: Azure CLI: https://learn.microsoft.com/cli/azure/release-notes-azure-cli Azure PowerShell: https://learn.microsoft.com/powershell/azure/release-notes-azureps Credential detection from Az CLIs outputs We have been actively working on hardening your defense in depth with secrets awareness in Azure command line tools. For Azure CLI and Azure PowerShell, in the past 6 months, we have collaborated with our internal team to replace verification patten with the Azure secret common library, expanding the coverage types of patches and the range of command lines. The range of command line detection has been almost 100% covered. The Azure CLI and Azure PowerShell use the same detection logic and are continually being upgraded. We still encourage users to enable environment parameters: AZURE_CLIENTS_SHOW_SECRETS_WARNING=True (Default) For Azure PowerShell only Our team is gradually transitioning to using SecureString for tokens, account keys, and secrets, replacing the traditional string types. Currently, we offer an opt-in method for the Get-AzAccessToken command line, which does not introduce breaking changes: Get-AzAccessToken –AsSecureString We encourage users to utilize the -AsSecureString parameter to output tokens securely. Over the next year, we plan to implement this security method across more command lines, converting all keys, tokens, and similar data from string types to SecureString. Please note that when the command line output defaults to -AsSecureString mode, it may result in breaking changes. Therefore, we advise users to stay updated with our breaking change documentation. Support Azure Linux 3.0 for Azure CLI Azure CLI has supported Azure Linux 3.0 from 2.65.0. The Azure Linux 3 user can install CLI with tdnf install azure-cli Starting from version 2.64.0 of Azure CLI, the base Linux distribution of Azure CLI is now Azure Linux 3.0. It’s available at Microsoft Artifact Registry (MAR) https://mcr.microsoft.com/en-us/artifact/mar/azure-cli/about. You can get it with the below command： docker pull mcr.microsoft.com/azure-cli or docker pull mcr.microsoft.com/azure-cli:azurelinux3.0 For further migration guidance especially involved with GitHub Actions, please check out more details from blog. Deprecate SP with certificate with az login –password for Azure CLI For az login, --password will no longer accept service principal certificate in Azure CLI 2.67.0. Use `--certificate` to pass a service principal certificate. # Logging in with secret should work as before az login --service-principal --username xxx --password mysecret --tenant xxx # Old way to log in with a certificate, will show a deprecation warning az login --service-principal --username xxx --password ~/mycert.pem --tenant xxx # New way to log in with a certificate az login --service-principal --username xxx --certificate ~/mycert.pem --tenant xxx Note: To sign in with a certificate, the certificate must be available locally as a PEM or DER file in ASCII format. PKCS#12 files (.p12/.pfx) don't work. When you use a PEM file, the PRIVATE KEY and CERTIFICATE must be appended together within the file. You don't need to prefix the path with an `@` like you do with other az commands. Azure PowerShell WAM Authentication Issues and Fixes Since version Az 12.0.0, Azure PowerShell has supported Web Authentication Manager (WAM) as the default authentication mechanism. During this period, several critical issues affected users logging in interactively. These issues have been addressed and fixed by version 13.0.0, including: The WAM login interface failing to pop up, resulting in login failures. Login failures for users using the device-code authentication method. The "Work and school account" option does not appear in the WAM pop-up window. Incompatibility of the Export-AzSshConfig and Enter-AzVM commands from the Az.Ssh module when WAM is enabled. For detailed announcements on specific issues, please refer to our WAM issues and Workarounds/azure-powershell issue. In response to these WAM issues, our team has been actively fixing bugs, making improvements, and establishing monitoring and alert mechanisms with relevant teams to detect issues early and assess their impact. Additionally, we have integrated test cases baseline into the release pipeline. We encourage users to enable the WAM function for security by using the command: Update-AzConfig -EnableLoginByWam $true If you encounter problems, please report them in Issues · Azure/azure-powershell Note: Sovereign Cloud does not currently support WAM, we plan to implement this in the coming months. Change in Azure CLI extension management Starting with Azure CLI version 2.56.0, a new `--allow-preview` parameter was introduced for the extension installations, with its default value set to True. This change, as outlined in our extension versioning guidelines, helps distinguish between stable and preview versions, ensuring consistency across stable releases while still enabling the publication of preview features. Beginning with version 2.67.0, Azure CLI will now install only stable versions of extension modules by default. If a later preview version of an extension is available, users will receive a warning message that explains how to enable preview versions by using the `--allow-preview` parameter. Important Note: If no stable version of an extension is available, preview versions will be installed by default, along with a warning message, like below, notifying users of this behavior. "No stable version of 'xxx' to install. Preview versions are allowed." Azure PowerShell Long Term Support releases (LTS) support Azure PowerShell already supports both Standard Term Support releases (STS) and Long-Term Support releases (LTS). Users can choose the appropriate version according to their project needs. Users can choose to stay with the LTS version until the next LTS version, or upgrade with the latest version to experience new features. The following document details the definitions of LTS and STS. Beginning with Az 12, even numbered releases are LTS versions. Azure PowerShell support lifecycle: Azure PowerShell support lifecycle | Microsoft Learn Azure CLI will provide LTS version in early 2025. More details could be found at Azure CLI lifecycle and support | Microsoft Learn Enhancement to Invoke-AzRestMethod in Azure PowerShell Azure PowerShell 13.0.0 introduces major enhancements to the Invoke-AzRestMethod cmdlet, empowering users with a new option to enable long-running operations (LRO) and flexible control over operation status polling in complex Azure workflows. Key Features of Invoke-AzRestMethod Enhancement: LRO Support with Enhanced Status Tracking: With the new -WaitForCompletion parameter, users can wait for the operations to complete and directly receive the final status. In debug mode, users can also monitor long-running operations (such as deployments or resource provisioning) and receive real-time status updates directly in their PowerShell session. Flexible Polling Options for Customized Control: The addition of -PollFrom and -FinalResultFrom parameters enable users to define custom polling URIs and specify final result header sources, ensuring compatibility across various Azure resources and scenarios. Example Usage: Using the new -WaitForCompletion parameter, here’s how to create a Managed HSM (Hardware Security Module) and track its provisioning status until it’s fully completed: Invoke-AzRestMethod -Method PUT -WaitForCompletion -Path "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.KeyVault/managedHSMs/{hsmName}" This example monitors the creation of a Managed HSM, providing real-time updates throughout the longer provisioning process (in debug mode), ensuring the resource reaches a fully operational state. For more details and examples, refer to the updated release notes: Azure PowerShell release notes Azure CLI/PS scenarios with Copilot in Azure In the second half of 2024, we improved knowledge of Azure CLI commands and end-to-end scenarios for Copilot in Azure to answer questions related to Azure CLI commands or scripts, following our best practices. In the past 6 months, we have optimized the following scenarios: Enhanced Prompt Flow and RAG architecture tailored for CLI script generation, ensuring higher command and scenario accuracy. Improved user intent recognition with hybrid search, enabling more precise retrieval of relevant knowledge from user queries. Supported parameter value injection, simplifying the process for customers to input parameter values and generate directly usable scripts on Copilot in Azure. Optimized the knowledge base to reduce hallucination issues. More accurately identified out-of-scope questions. In the 2024 Ignite Event, we’ve also released a public preview of AI Shell, which lets you access Copilot in Azure to help answer any questions you have about Azure CLI or Azure PowerShell. For more information about the AI Shell release please check out. AI Shell To learn more about Microsoft Copilot for Azure and how it can help you, visit: Microsoft Copilot for Azure Breaking Changes The latest breaking change guidance documents can be found at the links below. To read more about the breaking changes migration guide, ensure your environment is ready to install the newest version of Azure CLI and Azure PowerShell. Azure CLI: Release notes & updates – Azure CLI | Microsoft Learn Azure PowerShell: Migration guide for Az 13.0.0 | Microsoft Learn Milestone timelines: Azure CLI Milestones Azure PowerShell Milestones Thank you for using the Azure command-line tools. We look forward to continuing to improve your experience. We hope you enjoy Ignite and all the great work released this week. We'd love to hear your feedback, so feel free to reach out anytime. GitHub: https://github.com/Azure/azure-cli https://github.com/Azure/azure-powershell Let's be in touch on X (Twitter) : @azureposh @AzureCli Azure CLI and Azure PowerShell teamAzure Landing Zones Accelerators for Bicep and Terraform. Announcing General Availability!
Azure Landing Zones Accelerators are designed to simplify the process of onboarding your Infrastructure as Code into a robust CI / CD pipeline with Azure DevOps or GitHub. Learn more about what the Accelerator can do for you and why you should be using it.Announcing a new login experience with Azure PowerShell and Azure CLI
“You never get a second chance to make a first impression” said Will Rogers, this also applies to the Azure CLI and Azure PowerShell with the first command to execute. After hearing from our customers, our team spent the last few months improving the first experience of the Azure client tools. The new experience prioritizes access to usable information and shorter path to selecting your subscription.Azure CLI and PowerShell Tools Build 2024 Announcement
The priority for Azure CLI and Azure PowerShell remains to provide our customers with the most complete, secure, and easy-to-use tools to manage Azure resources. At Microsoft Build 2024, we are announcing the following new capabilities delivering on our priorities: Extending our coverage and commands API version upgrade. Improvements in user login experience. Security improvements. Invested in Copilot in Azure
