Azure Key Vault Control Plane API Update: Required Upgrade for Azure CLI and Azure PowerShell Users
Deadline: February 27, 2027 All Azure Key Vault control plane (management) API versions released before 2026-02-01 will stop working on February 27, 2027. This does NOT affect the data plane (getting/setting secrets, keys, and certificates) — only vault and access-control management operations are impacted. TL;DR — What you need to do Upgrade Azure CLI to 2.90.0 or later (run az upgrade). Upgrade Az PowerShell's Az.KeyVault module to 6.7.0 or later, or upgrade the Az package to 16.3.0 or later. Do this before February 27, 2027 to avoid any interruption to vault management operations. No data plane changes are required — reading/writing secrets, keys, and certificates is unaffected. For details, see Prepare for Key Vault API version 2026-02-01 and later. What is changing Current releases of Azure CLI 2.90.0 or later and Az PowerShell 16.3.0 or later (including Az.KeyVault 6.7.0 or later) already use Key Vault control plane API version 2026-02-01. Upgrade to these versions before February 27, 2027; after that date, earlier control plane API versions will no longer be served. Who is affected You are affected if you use either of the following: Azure CLI scripts or automation that call az keyvault management commands (create, update, network-rule, access-policy, etc.). Az PowerShell scripts that use the Az.KeyVault module's management cmdlets (New-AzKeyVault, Set-AzKeyVault, Update-AzKeyVault, etc.). Minimum versions to upgrade to Tool / SDK Minimum version How to upgrade Azure CLI 2.90.0 or later az upgrade Az PowerShell (Az.KeyVault module) Az.KeyVault 6.7.0 or later; or Az 16.3.0 or later Update-Module Az -Force Impact if you take no action What breaks on and after February 27, 2027 if you have not upgraded Key Vault management operations (create/update/delete vault, change network rules, change access policies or RBAC settings, etc.) issued with a pre-2026-02-01 API version will fail. You’ll get the following error message: “Due to an RBAC security default, Key Vault's Resource Manager API versions older than 2026-02-01 will retire on 2027-04-01.” Your vaults are NOT deleted and existing secrets/keys/certificates remain fully accessible via the data plane — only management (control plane) operations are blocked. There is no way to opt out or request an extension once the retirement takes effect on February 27, 2027. How to check your installed versions Check your Azure CLI version Run the following command: az version Check the azure-cli value. If the installed version is earlier than 2.90.0, upgrade Azure CLI before February 27, 2027 by running az upgrade. Check your Az PowerShell version Run the following commands: Get-InstalledModule Az, Az.KeyVault | Select-Object Name, Version If Az.KeyVault is earlier than 6.7.0, or the installed Az package is earlier than 16.3.0, upgrade before February 27, 2027. To upgrade the complete Az package, run: Update-Module Az -Force Alternatively, to update only the Az.KeyVault module to the latest version, run: Update-Module Az.KeyVault -Force Timeline Date Milestone March 2026 Control plane API version 2026-02-01 generally available across public Azure regions, Azure Government, and Azure operated by 21Vianet. Today → February 27, 2027 Preparation window. Upgrade to Azure CLI 2.90.0 or later, Az.KeyVault 6.7.0 or later, or Az 16.3.0 or later before February 27, 2027. February 27, 2027 All control plane API versions released before 2026-02-01 are retired and stop being served. Questions? For any questions about Azure CLI or Azure PowerShell, please submit feedback through GitHub: Azure CLI GitHub issues Azure PowerShell GitHub issues
Building a Fully Automated Azure Landing Zone Deployment Using Azure DevOps and Terraform
Discover how to build a fully automated Azure Landing Zone using Azure DevOps and Terraform. This article walks through real-world Git workflows, CI/CD automation, environment promotion strategies, and governance integration to create secure, scalable, and enterprise-ready Azure environments.Faster az login: introducing --skip-subscription-discovery and targeted --subscription
TL;DR — If you belong to many tenants, or a tenant holds hundreds or thousands of subscriptions, az login can crawl — it tries to enumerate every subscription in every tenant before it returns. Two flags now let you skip that enumeration and make login near-instant: az login --tenant <TENANT_ID> --skip-subscription-discovery az login --subscription <SUB_ID_OR_NAME> az login --tenant <TENANT_ID> --subscription <SUB_ID_OR_NAME> --skip-subscription-discovery Available in Azure CLI 2.86.0 and later. Both --skip-subscription-discovery (and its --skip-sub alias) ship in az CLI v2.86.0. Run az version to check, and az upgrade if you're on an older build. Note: --skip-subscription-discovery requires --tenant. Because you're skipping the tenant/subscription enumeration, the CLI can't infer which tenant to sign in to, so you must name it explicitly. Running az login --skip-subscription-discovery on its own fails with usage error: '--skip-subscription-discovery' requires '--tenant'. The problem: login enumerates every subscription in every tenant This post is about one specific pain point: what happens when you have a large number of tenants, and tenants that each contain hundreds or thousands of subscriptions. When you run az login, the CLI doesn't just authenticate you. After auth, it walks every tenant you can access and calls ARM to list every subscription in each one, then caches the full catalog locally. The cost of that step scales with (number of tenants) × (subscriptions per tenant) — so it's roughly invisible for a developer with one tenant and a couple of subscriptions, but it falls off a cliff at enterprise scale: A user who is a member or guest of dozens of tenants pays a separate ARM round trip per tenant. A single tenant with hundreds or thousands of subscriptions means one giant (often paged) enumeration just to build a list you may never look at. Put both together — many tenants, each dense with subscriptions — and the enumeration dominates everything. The interactive sign-in is fast; the post-auth subscription discovery is what makes you wait. In these high-scale tenant/subscription topologies, az login taking 30 seconds to several minutes is common — and almost all of that time is the discovery walk, not authentication. That is exactly the cost these flags remove. Other situations (CI/CD pinned to one known subscription, conditional-access tenants, etc.) benefit too, but they're secondary. The flags exist first and foremost to rescue the many-tenants / many-subscriptions case. What's new 1. --skip-subscription-discovery (alias --skip-sub) Authenticate only. Skip the subscription enumeration entirely. No tenant fan-out, no ARM GET /subscriptions calls per tenant. This flag requires --tenant — since discovery is skipped, you must tell the CLI which tenant to authenticate against. az login --tenant <TENANT_ID> --skip-subscription-discovery # or the short form az login --tenant <TENANT_ID> --skip-sub After this, az account list will be empty until you explicitly populate it (e.g. by az login --subscription <id> later, or by running a command that targets a subscription you know). The flag is independent of how you authenticate — interactive (the WAM account picker or browser), device code, service principal, or managed identity all work the same way. You complete your normal sign-in, just without the subscription enumeration afterward. Best for: Users who belong to many tenants, or tenants with hundreds-to-thousands of subscriptions — this is where the win is biggest, because you skip the enumeration that scales with (tenants) × (subscriptions per tenant). Pin the one subscription you need via --subscription or AZURE_SUBSCRIPTION_ID. Local developers who hit az login dozens of times a day and only ever work in one subscription. (You'll still get the interactive WAM account picker — that's the auth step; only the post-auth subscription enumeration is skipped.) Secondary: CI/CD with service principals or managed identities that already know the exact subscription, and cross-tenant guests who don't need the full catalog every login. What you'll see: --skip-subscription-discovery does not suppress the interactive sign-in prompt — it only skips the post-auth tenant/subscription enumeration. On an interactive login (no cached or still-valid token), the Web Account Manager (WAM) account picker still appears so you can authenticate; the flag simply skips the catalog fetch after you've signed in. The screenshot below is Windows, where the broker (WAM) drives sign-in. On Linux and macOS there's no WAM — the interactive step is a browser redirect (or a device code in headless/SSH environments) instead. The flag's behavior, and the performance win, are identical on every platform; only this sign-in UI differs. 2. Targeted --subscription <id-or-name> on az login Sign in and set a specific subscription as the active context in one step. az login --subscription 00000000-0000-0000-0000-000000000000 az login --subscription "Contoso Production" The CLI authenticates and sets the subscription you named as active. But note: on its own, --subscription does not skip discovery — the CLI still enumerates every tenant and every subscription you have access to, and only then selects the one you named as active. So if you have many subscriptions, this is still slow; you've just saved yourself a follow-up az account set. To actually skip the full fetch, combine it with --skip-subscription-discovery (see below). 3. The combo az login --tenant <TENANT_ID> --subscription <SUB_ID> --skip-subscription-discovery You get: authenticated session + active subscription set + zero tenant fan-out. With both flags, the CLI fetches only the subscription you named and skips the global enumeration entirely — this is the only way to get both a pinned subscription and a fast login. It's the fastest path to a working CLI for a known target. How much faster? Real-world impact scales with how many tenants you belong to and how many subscriptions each tenant holds — the bigger that product, the more you save. Order-of-magnitude observations from the field: Profile Typical az login time With --skip-subscription-discovery 1 tenant, 1–3 subs (typical dev) ~3–5 s ~2–3 s 1 tenant, hundreds–thousands of subs 20–60+ s ~2–3 s Many tenants, each with hundreds+ subs (the headline case) 1–several minutes ~2–3 s CI/CD with service principal, 1 known sub 5–10 s ~1 s The savings come entirely from cutting the per-tenant ARM enumeration — and they grow the more tenants and subscriptions you have. When not to use these flags You genuinely don't know which subscription you need and rely on az account list / az account set after login to pick. Plain az login is still the right call. You manage resources across many subscriptions in one session. Without discovery, az account list will be empty and tab-completion of subscriptions won't work. (Tip: run a one-time az account list --refresh later to populate.) First-time setup on a new machine where you want to see what you have access to. Try it now Make sure you're on a recent az CLI: az version az upgrade # if needed Then: az login --tenant <your-tenant> --subscription <your-sub> --skip-subscription-discovery az group list -o table Links & references az login reference (official docs) — full flag list including --skip-subscription-discovery / --skip-sub and --subscription: https://learn.microsoft.com/en-us/cli/azure/reference-index?view=azure-cli-latest#az-login Sign in with Azure CLI (how-to) — https://learn.microsoft.com/en-us/cli/azure/authenticate-azure-cli Azure CLI release notes — https://learn.microsoft.com/en-us/cli/azure/release-notes-azure-cli Feedback wanted If this changes your day-to-day login experience — especially if you live across many tenants with hundreds or thousands of subscriptions — we'd love to hear from you. Concrete before/after timings for those high-scale topologies are gold. Found a bug or have a feature request? File an issue on the Azure CLI repo: https://github.com/Azure/azure-cli/issues/new/chooseAzure CLI on macOS: Upcoming Installation Changes
From Homebrew Core to a new installation model for macOS Over the past few years, Azure CLI usage on macOS has continued to grow—across individual developers, open source contributors, and large enterprises. As adoption increases, so do expectations around security, reliability, and enterprise readiness. Starting with Azure CLI 2.86.0, we are beginning an important evolution of the macOS experience by introducing new installation options, initially available as Preview: Homebrew Cask (recommended) Offline / air-gapped tarball (.tar.gz) This post explains why these changes are necessary, what is different from before, and how we recommend customers think about the transition. Detailed installation and usage steps are documented on Microsoft Learn. Why are we changing how Azure CLI is installed on macOS? Historically, Azure CLI on macOS has been distributed via Homebrew Core. This model has worked well for many years, especially for developer-focused, source-based tooling. However, as macOS and enterprise security requirements continue to evolve, this distribution model introduces real technical and compliance constraints. To support future enterprise-grade security scenarios on macOS, Azure CLI must be able to rely on: Precompiled, verified binaries Code signing and notarization requirements enforced by macOS These requirements represent a fundamental shift from how Homebrew Core is designed to operate. Why Homebrew Core is no longer sufficient Homebrew Core is optimized for source-driven and fully open-source software distribution. Formulae in Homebrew Core are typically built from source or rely on build processes that are fully transparent and reproducible within the Homebrew ecosystem. As Azure CLI evolves, this model is no longer sufficient for several reasons: Future macOS authentication capabilities depend on platform-level components, not just Python code. These components integrate with the macOS Keychain and system-level security features. Such components must be distributed as precompiled binaries, rather than built from source during installation. On macOS, these binaries must be cryptographically signed and notarized to meet security and compliance requirements. Because of these constraints, continuing to rely solely on Homebrew Core would limit Azure CLI’s ability to support important enterprise scenarios on macOS going forward. Why Homebrew Cask Homebrew Cask is designed to distribute prebuilt, signed software on macOS. It provides a packaging model that aligns with modern macOS security expectations while preserving a familiar Homebrew experience. By moving to Homebrew Cask, Azure CLI can: Ship precompiled, signed artifacts Better align with evolving macOS security requirements Enable future support for more secure authentication scenarios on macOS, such as broker-based authentication This change is about establishing a durable installation foundation, not forcing changes to users’ current authentication experience. New installation options in Azure CLI 2.86.0 (Preview) Starting with Azure CLI 2.86.0, we are introducing two new installation options on macOS, both initially available in Preview. Homebrew Cask (recommended) Homebrew Cask is the recommended installation path moving forward. It provides: A familiar Homebrew-based workflow A self-contained, prebuilt bundle A distribution model aligned with evolving macOS security requirements During the Preview period, Homebrew Core remains available. We recommend users explore and adopt Homebrew Cask where appropriate and share feedback during this phase. Offline / air-gapped tarball For environments where Homebrew is not available or permitted—such as restricted or air-gapped enterprise environments—we are also introducing an offline tarball installation option. This option: Uses the same Azure CLI artifact as Homebrew Cask Supports both Apple Silicon and Intel Macs Allows full control over installation paths and Python runtimes The difference between these two options lies in how the same artifact is installed and managed, not in Azure CLI functionality. Preview now, GA later Both installation options are currently in Preview as part of Azure CLI 2.86.0. During this phase, we are focused on: Collecting feedback from real-world usage Validating behavior across macOS versions and architectures Identifying and addressing issues before broader rollout The timeline for General Availability is not finalized. We will communicate clearly with customers ahead of any GA transition or required changes. How we recommend customers proceed We recommend customers start adopting the new installation options during the Preview phase. Homebrew Cask is expected to become the standard installation model for Azure CLI on macOS. Adopting it early helps ensure a smoother transition as we move toward that model. During Preview, we encourage users to try the new experience and share feedback to help us refine it before broader rollout. Detailed installation and configuration steps are available on Install Azure CLI on macOS - Preview | Microsoft Learn Feedback: https://github.com/Azure/azure-cli/issuesAzure 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 @AzureCliAzure CLI Windows MSI Upgrade Issue: Root Cause, Mitigation, and Performance Improvements
Azure CLI on Windows MSI Upgrade Issue Summary About six months ago, some Windows users experienced an Azure CLI crash after upgrading via the MSI installer from Azure CLI 2.76.0 (or earlier) to 2.77.0 (or later). The failure occurred immediately on startup with: “ImportError: DLL load failed while importing win32file: The specified module could not be found.” This post explains what happened, why upgrades were affected (while clean installs typically worked), and what you can do to recover. Who is affected? You are likely affected if: You installed Azure CLI using the Windows MSI installer. You upgraded from Azure CLI 2.76.0 (or earlier) to 2.77.0 (or later) without fully uninstalling first. After the upgrade, any az command fails with the win32file ImportError on startup. Symptoms Typical error output (Azure CLI/Azure PowerShell): ImportError: DLL load failed while importing win32file: The specified module could not be found. Immediate recovery Upgrade to the latest version 2.83.0 If you want to install other versions of Azure CLI, perform a clean reinstall by uninstalling Microsoft Azure CLI from Windows Settings → Apps, deleting any remaining install folder (such as the CLI2 directory), reinstalling the latest Azure CLI using MSI or winget, and then verifying the installation with az --version. Root cause analysis During an affected MSI upgrade, the Azure CLI installation directory ended up missing a set of native Python extension files (.pyd files) required by the Windows integration layer. MSI logging showed components being blocked with messages indicating MSI believed the existing (older) key file was “newer” than the incoming one. The root cause was an interaction between Windows Installer file versioning rules and a third‑party dependency packaging change. Azure CLI 2.76.0/2.77.0 consumed pywin32 311, whose .pyd binaries were missing Windows version resource metadata. When upgrading from a previous Azure CLI build that contained version-stamped pywin32 binaries (e.g., pywin32 306), MSI could treat the older versioned files as higher priority than the incoming non-versioned files. As a result, MSI could remove the old files during upgrade but skip installing the new ones, leaving the install incomplete. Version mapping observed Azure CLI version Python pywin32 pywin32 .pyd version resource ≤ 2.75.0 3.12 306 Present (e.g., 3.12.306.0) 2.76.0 3.12 311 Missing / empty 2.77.0+ 3.13 311 Missing / empty If you need to collect MSI logs （for support） Run the installer with verbose logging （example）: msiexec /i "azure-cli-2.77.0.msi" /l*vx "C:\temp\azure-cli-install.log" References https://github.com/Azure/azure-cli/issues/32045#issuecomment-3669161120 Windows MSI Upgrade Performance Optimization The MSI upgrade process for Azure CLI on Windows has been significantly improved. Previously, Windows Installer performed per‑file version comparisons—particularly expensive for Python runtime files—which made upgrades slow and sometimes inconsistent. With the new logic, which skips the comparison and performs an overwrite installation. Upgrades now use a streamlined clean‑install process, resulting in faster and more reliable MSI upgrades. Performance Improvements Scenario Before After Improvement Fresh Install Baseline ~5% faster 5% faster Upgrade Long due to file-by-file version comparison ~23% faster 23% faster This update makes upgrades noticeably faster and more reliable by removing old files first and skipping slow per‑file version checks. For more details, please refer to: [Packaging] Optimize MSI upgrade performance by simplifying file replacement logic by wangzelin007 · Pull Request #32678 · Azure/azure-cli We encourage you to upgrade to the latest version of the Azure CLI. This will not only resolve the issue but also improve installation performance. Here is our release note. If you encounter any problems, please feel free to report them on Azure CLI GitHub.Gaining Confidence with Az CLI and Az PowerShell: Introducing What if & Export Bicep
Ever hesitated before hitting Enter on a command, wondering what changes it might make? You’re not alone. Whether you’re deploying resources or updating configurations, the fear of unintended consequences can slow you down. That’s why we’re introducing new powerful features in Azure CLI and Azure PowerShell to preview the changes the commands may make: the What if and Export Bicep features. These capabilities allow you to preview the impact of your commands and allow you to export them as Bicep templates, all before making any changes to your Azure environment. Think of them as your safety net: you can validate actions, confirm resource changes, and even generate reusable infrastructure-as-code templates with confidence. Currently, these features are in private preview, and we’re excited to share how you can get early access. Why This Matters Reduce risk: Avoid accidental resource deletions or costly misconfigurations. Build confidence: Understand exactly what your command will do before execution. Accelerate adoption of IaC: Convert CLI commands into Bicep templates automatically. Improve productivity: Validate scripts quickly without trial-and-error deployments. How It Works What if preview of commands All you have to do is add the `--what-if` parameter to Azure CLI commands and then the `-DryRun` command to Azure PowerShell commands like below. Azure CLI: az storage account create --name "mystorageaccount" --resource-group "myResourceGroup" --location "eastus" --what-if Azure PowerShell: New-AzVirtualNetwork -name MyVNET -ResourceGroupName MyResourceGroup -Location eastus -AddressPrefix "10.0.0.0/16" -DryRun Exporting commands to Bicep To generate bicep from the command you will have to add the `--export-bicep` command with the --what-if parameter to generate a bicep file. The bicep code will be saved under the `~/.azure/whatif` directory on your machine. The command will specific exactly where the file is saved on your machine. Behind the scenes, AI translates your CLI command into Bicep code, creating a reusable template for future deployments. After generating the Bicep file, the CLI automatically runs a What-If analysis on the Bicep template to show you the expected changes before applying them. Here is a video of it in action! Here is another example where there is delete, modify and create actions happening all together. Private Preview Access These features are available in private preview. To sign up: Visit the aka.ms/PreviewSignupPSCLI Submit your request for access. Once approved, you’ll receive instructions to download the preview package. Supported Commands (Private Preview) Given these features are in a preview we have only added support for a small set of commands for the time being. Here’s a list of commands that will support these features during the private preview: Azure CLI Az vm create Az vm update az storage account create az storage container create az storage share create az network vnet create az network vnet update az storage account network-rule add az vm disk attach az vm disk detach az vm nic remove Azure PowerShell New-AzVM Update-AzVM New-AzStorageAccount New-AzRmStorageShare New-AzRmStorageContainer New-AzVirtualNetwork Set-AzVirtualNetwork Add-AzStorageAccountNetworkRule Next Steps Sign up for the private preview. Install the packages using the upcoming script. Start using --what-if, -DryRun, and --export-bicep to make safer, smarter decisions and accelerate your IaC journey. Give us feedback on what you think of the feature! At https://aka.ms/PreviewFeedbackWhatIf Thanks so much! Steven Bucher PM for Azure Client ToolsAzure CLI and Azure PowerShell Ignite 2025 Announcement
In 2025, the key investment areas for Azure CLI and Azure PowerShell are quality and security. We have also made significant efforts to improve the overall user experience. Meanwhile, AI remains a central theme. At Microsoft Ignite 2025, we are pleased to announce several new features related to these priorities: In terms of security: MFA enforcement Azure CLI Upgrade and Python 3.13 Compatibility explanation New feature: Azure CLI and Azure PowerShell -What-If and -export bicep parameter Extending our coverage We’ve rolled out significant updates across Azure CLI and Azure PowerShell to enhance functionality: Azure CLI and Azure PowerShell Upgrades Services updated: ACR, ACS, AKS, App Config, App Service, ARM, ARO, Backup, Batch, Cloud, Compute, Consumption, Container, Container app, Core, Cosmos DB, Cognitive Services, DMS, Eventhub, HDInsight, Identity, IoT, Key Vault, MySQL, NetAppFiles, Network, Packaging, Profile, RDBMS, Service Fabric, SQL, Storage. New Extensions for Azure CLI and Azure PowerShell Extensions added: arize-ai,connectedmachine,containerapp,lambda-test,migrate,neon,pscloud,sftp,site,storage-blob-preview. New GA Modules for Azure CLI and Azure PowerShell Modules are now generally available: DeviceRegistry, DataMigration, FirmwareAnalysis,LoadTesting,StorageDiscovery , DataTransfer, ArizeAI, Fabric, StorageAction, Oracle For detailed release notes: Azure CLI: https://learn.microsoft.com/cli/azure/release-notes-azure-cli Azure PowerShell: https://learn.microsoft.com/powershell/azure/release-notes-azureps Azure CLI Upgrade and Python 3.13 Compatibility Notes Azure CLI has been upgraded from version 2.76 to 2.77 primarily to address several security vulnerabilities (CVE), including issues related to remote code execution risks and certificate validation flaws in underlying dependencies, ensuring compliance with the latest security standards. This upgrade requires Python to move from 3.12 to 3.13, which introduces a significant change: Python 3.13 enforces stricter SSL verification rules, causing failures for users running behind proxies that intercept HTTPS traffic. Solution: Update your proxy certificate to comply with strict mode. For instance, Mitmproxy fixed this in version v10.1.2 (reference: https://github.com/Azure/azure-cli/issues/32083#issuecomment-3274196488). For more Python3.13 details, see What’s New In Python 3.13 . Handling Claims Challenges for MFA in Azure CLI and Azure PowerShell Claims challenges appear when ARM begins enforcing MFA requirements. If a user performs create, update, or delete operations without the necessary MFA claims, ARM rejects the request and returns a claims challenge, indicating that higher-level authentication is required before the API call can proceed. This mechanism is designed to ensure sensitive operations are performed only by users who have completed MFA. The challenge arises because Azure CLI and Azure PowerShell can only acquire MFA claims during the login phase, and only if the user’s account is configured to require MFA. Changing this setting affects all services associated with the account, and many customers are reluctant to enable MFA at the account level. As a result, when a claims challenge occurs, Azure CLI and Azure PowerShell cannot automatically trigger MFA in the same way Azure Portal does. Azure CLI example: az login --tenant "aaaabbbb-0000-cccc-1111-dddd2222eeee" --scope "https://management.core.windows.net//.default" --claims-challenge "<claims-challenge-token>" For more details, see: Azure CLI: Troubleshooting Azure CLI | Microsoft Learn Azure PowerShell example: Connect-AzAccount -Tenant yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyy -Subscription zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzz -ClaimsChallenge <claims-challenge-token> For more details, see: Azure PowerShell: Troubleshooting the Az PowerShell module | Microsoft Learn Advanced cloud analysis capabilities, involving capacity insights or forecasting in Azure CLI With this update, Azure CLI now uses the latest ARM API version (2022-09-01) for endpoint discovery during cloud registration and updates, replacing the older API versions previously used. This ensures more accurate and up-to-date service endpoints, simplifies the configuration of custom Azure clouds, and improves reliability when retrieving required endpoints. By adopting the new API, Azure CLI stays aligned with the latest Azure platform capabilities, increasing both compatibility and forward-compatibility. As a result, users benefit from more accurate endpoint discovery and improved support for new Azure features and service endpoints as they become available. For more details about managing cloud environments in Azure CLI, please refer to the official documentation: Azure cloud management with the Azure CLI | Microsoft Learn Azure PowerShell - Add Pagination Support for 'Invoke-AzRestMethod' via '-Paginate' parameter Invoke-AzRestMethod is a flexible fallback for calling Azure Management APIs, returning raw HTTP responses from underlying endpoints, but it currently lacks built-in pagination, forcing users to implement custom logic when working with large datasets. Since pagination was not part of the original design, changing the default behavior could break existing scripts that depend on the current response format and nextLink handling. To address this without disruption, we plan to introduce pagination as an optional opt-in feature, enabling users to retrieve complete datasets through server-driven pagination without writing custom code while preserving the current behavior by default for full backward compatibility. For more details, see the official documentation for Invoke-AzRestMethod: Invoke-AzRestMethod (Az.Accounts) | Microsoft Learn Introducing Azure CLI and Azure PowerShell -What-If and -export bicep parameter We’re introducing two new features in both Azure CLI and Azure PowerShell: the What-If and Export Bicep parameters. The What-If parameter gives you an intelligent preview of which resources will be created, updated, or deleted before a command runs, helping you catch issues early and avoid unexpected changes. The Export Bicep parameter generates the corresponding Bicep templates to streamline your infrastructure-as-code workflows. Both features leverage AI to assist with command interpretation and template generation. If you’d like to try these capabilities in Azure CLI and Azure PowerShell, you can sign up through our form. Please stay tuned for more updates. 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 15.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: o https://github.com/Azure/azure-cli o https://github.com/Azure/azure-powershell Let's be in touch on X (Twitter) : @azureposh @AzureCli
Announcement of migrating to Azure Linux 3.0 for Azure CLI
Azure CLI 2.74.0 is the final version available on Azure Linux (Mariner) 2.0 and will not receive further updates. We recommend migrating to Azure Linux 3.0 to access newer versions of Azure CLI and continue receiving updates. A warning message will appear when using Azure CLI on Azure Linux 2.0. To suppress this message, set the AZURE_CLI_DISABLE_AZURELINUX2_WARNING environment variable to any value. We value the experiences of our Azure CLI users, especially when lifecycle changes might cause disruptions. Our goal is to provide clear communication and as much advance notice as possible. Quoting our internal partner, the Azure Linux team, as follows: Azure Linux 2.0 will reach its End of Life (EOL) on July 2025. After this date, it will no longer receive updates, security patches, or support, which may put your systems at risk. From today, we will not be entertaining package upgrade requests for Azure Linux 2.0. To ensure continued support, security, and performance, we strongly recommend upgrading to Azure Linux 3.0 by June 2025. Azure Linux 3.0 comes with enhanced features, better performance, and longer support, making it better choice for your infrastructure moving forward. Learn more about 3.0 here. We understand that migrations can take time, so we encourage you to begin planning your upgrade as soon as possible. Our Azure Linux team is available to assist with the transition, address any concerns, and help make the process as seamless as possible. Is this the same as Mariner? Yes, Mariner was rebranded to Azure Linux. We will slowly update our documentation and VM/container image tags to reflect this name change When did Azure Linux 3.0 GA? Azure Linux 3.0 became generally available in August 2024. When will Azure Linux 3.0 reach End of Life (EOL)? We currently support each major version for 3 years after it becomes generally available. Azure Linux 3.0 will reach EOL in Summer 2027. Azure CLI 2.74.0 (scheduled for release on 2025-06-03) is the final version to support Azure Linux 2.0. We strongly recommend reviewing your scenarios and using this transition period to ensure a smooth migration. For AKS customers, Noting that Azure Linux team are still supporting Azure Linux 2.0 until November 2025 to align with AKS v1.31 support. This means Azure Linux 2.0 is getting regular patches until November 2025. If you encounter any issues related to Azure CLI on Azure Linux 3.0, please open an issue in our GitHub repo.
Azure CLI Breaking Change Pre-Announcement
Background In our continuous effort to improve the quality and timeliness of our documentation, we have embarked on an initiative to automate the production of Upcoming Breaking Change Documentation. This initiative aims to alleviate the workload and pressure typically experienced before major events such as Microsoft Build and Microsoft Ignite. By leveraging automated methods, we can ensure that our documentation is both comprehensive and promptly available to our users. Streamlining the Process To further streamline this process, we are introducing a new workflow designed to encourage Service Teams to notify us of any future breaking changes several sprints ahead. The new workflow includes a new framework to pre-announce breaking changes, which will enable us to publish detailed and accurate Upcoming Breaking Change Documentation well ahead of time, providing our users with the information they need to prepare for these changes. Breaking Change Rule Core CLI A breaking change in Azure CLI refers to a modification that disrupts backward compatibility with previous versions, potentially causing scripts or automation written in earlier versions to fail. Common examples include modifying parameter names, input logic, result output format, behavior models, and adding additional verifications. To mitigate the impact, Azure CLI coordinates half-yearly Breaking Change Releases, bundling multiple breaking changes together. This approach helps users plan ahead and adapt effectively. Breaking Change Window The breaking change window is a designated sprint for merging service command breaking changes, aligning with Microsoft Build in May and Microsoft Ignite in November. Outside this window, breaking changes are typically prohibited to ensure consistency and stability. Exceptions require high-grade justifications and are assessed based on overall impact. 30-Day Pre-announcement Policy All breaking changes must be pre-announced 30 days (usually 2 sprints) before the release. This provides users with buffer time to adapt. Notifications are made through: Warning Log: Mandatory pre-announcement while executing. Upcoming Breaking Change Document: Automatic collection and listing of changes. Extensions All breaking changes in GA (General Available) extensions must be pre-announced at least 30 days prior to their release. While extensions do not need to follow the breaking change window, it is strongly recommended to align their releases with the Core Azure CLI breaking change window. GA (General Available) Release with Breaking Change Pre-Announcement Must include complete breaking change information. Must fulfill the 30-day announcement requirement. During the 30-day announcement period, releases are allowed for unrelated GA (General Available) versions and multiple preview releases (Beta versions). By adhering to these guidelines, users can ensure a smoother transition and maintain compatibility with their existing scripts and automation. How to Announce a Breaking Change It is simple to announce a Breaking Change using the new framework. Find the entry: Find or add an entry to the _breaking_change.py file in the top-level directory of the relevant module. Register Breaking Changes: You can then pre-announce breaking changes for different command groups or commands. Multiple breaking changes on the same command are accepted. from azure.cli.core.breaking_change import register_required_flag_breaking_change, register_default_value_breaking_change, register_other_breaking_change register_required_flag_breaking_change('bar foo', '--name') register_default_value_breaking_change('bar foo baz', '--foobar', 'A', 'B', target_version='May 2025') register_other_breaking_change('bar foo baz', 'During May 2024, another Breaking Change would happen in Build Event.') Try the Warning All related breaking changes will be displayed when executing the command. For instance, with the above declarations, the following warnings will be output when executing the command: # The azure command az bar foo baz # =====Warning output===== # The argument '--name' will become required in next breaking change release (2.61.0). # The default value of '--foobar' will be changed to 'B' from 'A' in May 2025. # During May 2024, another Breaking Change would happen in Build Event. Types of Breaking Changes There are several types of breaking changes defined in `_breaking_change.py`. You should use any of them to declare breaking changes: Remove Rename Output Change Change Default Change Be Required Other Changes Conditional Breaking Change Work with Breaking Change Detect To normalize the release of breaking changes, Azure CLI has integrated a Breaking Change Detection tool into the Pull Request Pipeline. This tool will reject any breaking changes that are submitted outside of the designated breaking change window and will provide guidelines for following the breaking change policies. Technical Implementation The Breaking Change Pre-Announcement uses a hook in the Azure CLI. This hook is used to collect announcements registered in _breaking_change.py files and transform them into tags that can be consumed by the Knack framework, which is the foundational framework used by the Azure CLI. When multiple tags are registered under the same identifier, they are consolidated into a single MergedTag. This MergedTag is then used to manage complex scenarios effectively. Conditional breaking changes are not transformed into tags. Instead, they are stored in the breaking changes registry. These changes can be accessed manually by calling the print_conditional_breaking_change function. Future Plan Detect out of date announcement Detect related announcements in PR of breaking changes
